%
% Exemplo LaTeX de monografia UNISINOS
%
% Elaborado com base nas orientações dadas no documento
% ``GUIA PARA ELABORAÇÃO DE TRABALHOS ACADÊMICOS''
% disponível no site da biblioteca da Unisinos.
% http://www.unisinos.br/biblioteca
%
% Os elementos textuais abaixo são apresentados na ordem em que devem
% aparecer no documento.  Repare que nem todos são obrigatórios - isso
% é devidamente indicado em cada caso.
%
% Comentários abaixo colocados entre aspas (`` '') foram
% extraídos diretamente do documento da biblioteca.
%
% Este documento é de domínio público.
%

%=======================================================================
% Declarações iniciais identificando a classe de documento e
% selecionando alguns pacotes adicionais.
%
% As opções disponíveis (separe-as com vírgulas, sem espaço) são:
% - twoside: Formata o documento para impressão frente-e-verso
%   (o default é somente-frente)
% - english,brazilian,french,german,etc.: idiomas usados no documento.
%   Deve ser colocado por último o idioma principal.
%=======================================================================
\documentclass[twoside,english,brazilian]{UNISINOSmonografia}
\usepackage[utf8]{inputenc} % charset do texto (utf8, latin1, etc.)
\usepackage[T1]{fontenc} % encoding da fonte (afeta a sep. de sílabas)
\usepackage{graphicx} % comandos para gráficos e inclusão de figuras
\usepackage{epstopdf}
\usepackage{bibentry} % para inserir refs. bib. no meio do texto

%=======================================================================
% Escolha do sistema para geração de referências bibliográficas.
%
% O default é usar o estilo unisinos.bst.  Comente a definição abaixo
% e descomente a linha seguinte para usar o estilo do ABNTeX (é
% necessário ter esse pacote instalado).
%
% A vantagem do unisinos.bst é que ele permite o uso de um arquivo .bib
% seguindo as orientações tradicionais do BibTeX (veja essas orientações
% em http://ctan.tug.org/tex-archive/biblio/bibtex/contrib/doc/btxdoc.pdf).
% Entretanto, o estilo não suporta algumas citações mais exóticas como
% apud.  Para isso, use o ABNTeX, mas esteja ciente de que muitas de
% suas referências serão incompatíveis com os estilos tradicionais do
% BibTeX como plain, alpha, ieeetr, entre outros.
%=======================================================================
\unisinosbst
%\usepackage[alf]{abntcite}

%=======================================================================
% Dados gerais sobre o trabalho.
%=======================================================================
\autor{Raguze Flores}{Roberto}
\titulo{Combinando ciência do contexto com comunicação 3G e sensores RFID 
aplicados ao comércio}
%\subtitulo{}
\orientador[Prof.~Dr.]{Da Rosa Righi}{Rodrigo}
%\coorientador[Prof.~Dr.]{Lamport}{Leslie}
\local{São Leopoldo}
\ano{2013}

%% dados específicos para Dissertação de Mestrado
%\unidade{Unidade Acadêmica de Pesquisa e Pós-Graduação}
%\curso{Programa de Pós-Graduação em Computação Aplicada}
%\nivel{Nível Mestrado}
%\natureza{%
%Dissertação apresentada como requisito parcial para a obtenção
%do título de Mestre pelo Programa de Pós-Graduação em Computação
%Aplicada da Universidade do Vale do Rio dos Sinos --- UNISINOS
%}
%% dados da ficha catalográfica (obrigatória somente para diss. e tese)
%\cip{Dissertação (mestrado)}{004.732}
%\bibliotecario{Bibliotecária responsável: Fulana da Silva}{12/3456}

%% dados específicos para monografia de Graduação
\unidade{Unidade Acadêmica Graduação}
\curso{Curso de Bacharelado em Ciência da Computação}
\natureza{%
Trabalho de Conclusão de Curso apresentado como requisito parcial
para a obtenção do título de Bacharel em Ciência da Computação
pela Universidade do Vale do Rio dos Sinos --- UNISINOS
}

% cada palavra-chave deve ser fornecida duas vezes, uma em português e
% outra no idioma estrangeiro (na verdade, em tantos idiomas quantos se
% desejar).
\palavrachave{brazilian}{RFID}
\palavrachave{brazilian}{Redes Móveis}
\palavrachave{brazilian}{Comércio Eletrônico}
\palavrachave{brazilian}{Internet das Coisas}
\palavrachave{brazilian}{Nuvens Móveis}
\palavrachave{english}{RFID}
\palavrachave{english}{Mobile Networks}
\palavrachave{english}{e-Commerce}
\palavrachave{english}{Internet of Things}
\palavrachave{english}{Mobile Clouds}


%=======================================================================
% Início do documento.
%=======================================================================
\begin{document}
\capa
\folhaderosto

%=======================================================================
% Dedicatória (opcional).
%
% O texto é normalmente colocado na parte de baixo da página, alinhado
% à direita.  Mas a formatação é basicamente livre.  Só não se escreve
% a palavra 'dedicatória'.
%=======================================================================
%TODO
\begin{dedicatoria}
Aos nossos pais.\\[4ex] % quebra a linha dando um espaçamento maior
\begin{itshape} % faz o texto ficar em itálico
If I have seen farther than others,\\
it is because I stood on the shoulders of giants.\\
\end{itshape}
--- \textsc{Sir Isaac Newton} % \textsc é o "small caps"
\end{dedicatoria}

%=======================================================================
% Agradecimentos (opcional).
%=======================================================================
%TODO
\begin{agradecimentos}
Obrigado!
\end{agradecimentos}

%=======================================================================
% Epígrafe (opcional).
%
% ``[...] o autor apresenta uma citação, seguida de indicação de autoria,
% relacionada com a matéria tratada no corpo do trabalho. Podem, também,
% constar epígrafes nas folhas de aberturas das seções primárias.''
%=======================================================================
%TODO Alguma frase do ray kurzweil, isaac asimov ou mark weiser
\begin{epigrafe}
``\textit{Ninguém abre um livro sem que aprenda alguma coisa}''.\\
(Anônimo)
\end{epigrafe}

%=======================================================================
% Resumo em Português.
%
% A recomendação é para 150 a 500 palavras.
%=======================================================================
%TODO
\begin{abstract}
Este documento apresenta orientações para uso da classe \LaTeX\ de formatação de monografias para a UNISINOS\@.  Ao mesmo tempo, ele serve como exemplo de uso da classe, demonstrando os principais comandos a serem utilizados, e outras orientações mais gerais de uso do \LaTeX.  Adicionalmente, procuramos incluir no documento algumas orientações sobre a escrita da monografia em si, reunindo dicas e recomendações que contribuem para aumentar a qualidade técnica dos trabalhos acadêmicos.  O Resumo deve conter de 150 a 500~palavras e nele não deve haver citações. Sugere-se a utilização de parágrafo único.
\end{abstract}

%=======================================================================
% Resumo em língua estrangeira (obrigatório somente para teses e
% dissertações).
%
% O idioma usado aqui deve necessariamente aparecer nos parâmetros do
% \documentclass, no início do documento.
%=======================================================================
%TODO
\begin{otherlanguage}{english}
\begin{abstract}
This document presents guidelines on the use of UNISINOS's \LaTeX\ class for academic reports and dissertations.  At the same time, it serves as an example on using the class, employing the main commands and providing further general orientations on the use of \LaTeX.  In addition, we have added guidelines for the process of writing itself, collecting tips and recommendations that contribute to the technical quality enhancement of academic monographs.  The Abstract should be composed of 150 to 500~words and must not contain any citations.  It is suggested that a single paragraph be used.
\end{abstract}
\end{otherlanguage}

%=======================================================================
% Lista de Figuras (opcional).
%=======================================================================
\listoffigures

%=======================================================================
% Lista de Tabelas (opcional).
%=======================================================================
\listoftables

%=======================================================================
% Lista de Abreviaturas (opcional).
%
% Deve ser passada como parâmetro a maior das abreviaturas utilizadas.
%=======================================================================
\begin{listadeabreviaturas}{seg., segs.}
\item[ampl.] ampliado, -a
\item[atual.] atualizado, -a
\item[coord.] coordenador
\item[N.~T.] Novo Testamento
\item[seg., segs.] seguinte, -s
\end{listadeabreviaturas}

%=======================================================================
% Lista de Siglas (opcional).
%
% Deve ser passada como parâmetro a maior das siglas utilizadas.
%=======================================================================
\begin{listadesiglas}{WSDL}
\item[RFID] Radio Frequency Identification
\item[IoT] Internet of Things
\item[PC] Personal Computer
\item[3G] Third Generation
\item[4G] Fourth Generation
\item[WiFi] Wireless Fidelity
\item[LAN] Local Area Network
\item[RF] Rádio Frequência
\item[EM] Ondas Eletromagnéticas
\item[ID] Identificação
\item[NFC] Near Field Communication
\item[UHF] Ultra High Frequency
\item[P2P] Peer-to-Peer
\item[ISO] International Organization for Stantardization
\item[IEC] International Electrotechnical Commission
\item[EPC] Electronic Product Code
\item[ALE] Application Product Code
\item[ONS] Object Name Service
\item[XML] Extensible Markup Language
\item[WSDL] Web Services Description Language
\item[LAN] Local Area Network
\item[WAN] Wide Area Network
\item[DNS] Domain Name System
\item[IP] Internet Protocol
\item[URL] Uniform Resource Locator
\item[SDK] Software Development Kit
\end{listadesiglas}

%=======================================================================
% Lista de Símbolos (opcional).
%
% Deve ser passado o maior (mais largo) dos símbolos utilizados.
%=======================================================================
\begin{listadesimbolos}{MB}
\item[Mbps] Mega bits por segundo
\item[ms] Mili segundos
\item[MB] Mega bytes
\item[MHz] Mega hertz
\item[Kbps] Kilo bits por segundo
\end{listadesimbolos}

%=======================================================================
% Sumário
%=======================================================================
\tableofcontents

%=======================================================================
% Introdução
%=======================================================================
\chapter{Introdução}

% as epígrafes nos capítulos são opcionais
\epigrafecap{The most profound technologies are those that disappear. They 
weave themselves into the fabric of everyday life until they are 
indistinguishable from it.}{Mark Weiser}

Uma tendência cada vez mais perceptível no mercado é a expansão dos 
\textit{smartphones} e \textit{tablets}. Assim, o crescimento dos dispositivos 
móveis é impulsionado pelo advento das tecnologias de comunicação sem fio e 
miniaturização dos elementos computacionais. Pela primeira vez, no ano de 
2011, os \textit{smartphones} tiveram suas vendas superiores aos tradicionais 
PCs \cite{joeweb:12}. De forma semelhante, cresce os aplicativos desenvolvidos 
para as plataformas móveis. Estima-se que o mercado global de aplicativos 
desse tipo atinja \$25 bilhões de dólares até o final de 2015 
\cite{emmanouilidis:13}.

Esses dados mostram que os dispositivos móveis estão cada vez mais presentes 
em nossas vidas. Novas necessidades estão sendo criadas com a utilização 
destes dispositivos, e mesmo sem notar, estamos mais dependentes dos mesmos. 
Esta nova experiência móvel permite que delegamos tarefas corriqueiras do dia 
a dia, liberando nossa mente para focarmos o pensamento no que realmente 
precisa da atenção e da sabedoria humana. Nós estamos, sobretudo, mudando 
nossa forma de pensar em sobre computadores. O foco antes dado as máquinas 
especializadas com poder computacional e conectividade, agora considera o 
mundo humano, e permite que os computadores desapareçam no plano de fundo. 
Como descreveu o visionário \citetexto{weiser:91}:
\begin{quote}
elementos especializados de hardware e software conectados por cabos, 
ondas de rádio e infravermelho, serão tão ubíquos que ninguém notará suas 
presenças.
\end{quote}

Logo, o conceito de computação ubíqua cunhado por Mark Wieser está cada vez 
mais presente no mundo atual. O seu objetivo é tornar a interação humano-
computador cada vez mais natural através da gerência do contexto e da 
mobilidade \cite{weiser:91}. O conceito de computação ubíqua é explorado tanto 
na ciência quanto no mercado em geral, dada situação atual da 
computação. O contexto pode ser obtido através da análise de uma rede de 
sensores. Por exemplo, o \textit{Radio Frequency IDentifier}, RFID, é um tipo 
de sensor de baixo custo, cuja tecnologia vem amadurecendo ao longo dos 
últimos anos, e pode ser lido por diversos dispositivos móveis. Mesmo com as 
primeiras patentes da tecnologia registradas em 1973 nos Estados Unidos 
\cite{chae:10}, é recente o uso industrial da tecnologia. Encontram-se 
aplicações em uma gama variada de sistemas de manufatura, controle de estoque, 
rastreamento de objetos, transportes e logística, ambientes inteligentes e 
assistência médica. 

Com a utilização da tecnologia RFID é possível coletar informações 
instantâneas com precisão sobre a localização e o histórico de produtos 
através da identificação e rastreamento de cada um \cite{chae:10}. Apesar do 
foco industrial estar voltado principalmente para estas aplicações da 
tecnologia, o RFID pode ser, em sentido amplo, utilizado para endossar redes 
de comunicação de curto alcance. A rede \emph{Wal-Mart} dos Estados Unidos, 
uma gigantesca corporação do setor varejista, empregou a tecnologia RFID em 
toda sua cadeia logística. Como resultado, obteve a redução em 30\% do 
esgotamento de itens no estoque, aumentando a renda líquida da empresa em 
\$15,35 bilhões de dólares \cite{want:04}. Outras organizações também 
apresentam casos de sucesso com a utilização da tecnologia RFID. O 
Departamento de Defesa dos Estados Unidos está cogitando o uso da tecnologia 
em aplicações militares \cite{ullah:12}. Etiquetas eletrônicas seriam 
utilizadas para identificar e rastrear ıtens de carga desde a origem até seu 
destino.

As redes de comunicação móveis também têm ganhado cena nos últimos anos. Com o 
grande desenvolvimento das redes móveis de amplo alcance como 3G e 4G, 
presenciamos o crescimento do acesso à internet móvel ao longo do globo. A 
internet é um ponto chave na ciência do contexto, uma vez que ela propicia o 
compartilhamento de informações sensoriais e proporciona a integração 
transparente de tecnologias e dispositivos.

Com o desenvolvimento da internet e comunicação sem fio, aplicativos móveis 
são cada vez mais aceitáveis e utilizados. Sistemas de comunicação móvel e a 
tecnologia RFID quando integrados à uma infraestrutura de rede sem fio, 
resultam em uma tecnologia RFID móvel. Esta tecnologia pode, além de abrir 
novos mercados e serviços, formar um ambiente de computação pervasiva 
\cite{liu:11}, que aproxime o mundo digital cada vez mais do mundo físico. 
Este fenômeno da computação pervasiva, alimentado por redes de comunicação e 
identficação única de dispositivos, envolto a ciência do contexto, é conhecido 
como internet das coisas \cite{atzori:2010}.

Todavia, mesmo com o crescimento exponencial da tecnologia, o poder 
computacional dos dispositivos móveis e futuramente das "coisas" é muito 
limitado quando comparados à um computador doméstico, quiçá um super 
computador.  Embora o poder computacional dos \textit{smartphones} estar quase 
superando os computadores e \textit{notebooks} --- o \textit{iPhone} da Apple
\footnote{http://www.apple.com} e o \textit{Galaxy IV} da Samsung
\footnote{http://www.samsung.com} ambos apresentam modelos \textit{dual core} 
com gigaherts de velocidade de processamento --- eles constituem apenas uma 
parcela dos dispositivos que interconetados constituem a internet das coisas.

A quantidade de informações produzidas pelo homem no último século é maior do 
que todas as informações da história da humanidade até então. E a tendência 
desses dados é crescer cada vez mais, podendo dobrar sua quantidade a cada 
ano. Um contribuidor significativo para tal volume de informações são as redes 
sociais, acessados tanto por dispositivos móveis quanto por computadores, no 
qual pessoas do mundo inteiro compartilham informações a todo instante. 
Semelhantemente à venda de \textit{smarphones}, o acesso as redes sociais por 
meio dos dispositivos móveis é cada vez maior. De acordo com Ethan Beard, 
diretor de plataformas de parceiros do Facebook, 350 milhões de usuários 
dentre os 800 milhões de usuários da rede social no mundo inteiro estão 
acessando-a através do \textit{smartphone} \cite{ocarroll:11}. Além disso, os 
usuários que utilizam \textit{smartphones} para acessar as redes sociais são 
mais engajados, segundo dados disponibilizados pelas redes Facebook
\footnote{http://www.facebook.com} e Twitter\footnote{http://www.twitter.com}. 
O Twitter divulgou que sua audiência móvel é mais engajada que o média dos 
usuários, uma vez que seguem mais marcas, interagem mais com \textit{tweets} e 
gastam mais tempo usando o serviço \cite{mcgee:13}. Este efeito de engajamento 
é proeminente da ciência do contexto que aliado aos sensores e a 
miniaturização dos dispositivos móveis buscam dar vida a computação pervasiva, 
já mostrando os primeiros passos do que será a internet das coisas.

Mas com  tantos dados sendo gerados a todo instante, e dispositivos móveis 
cada vez menores entrando em cena, como essa grande massa de dados poderá ser 
analisada e utilizada em prol da computação pervasiva? Com certeza um 
dispositivo único não terá poder computacional o suficente para processar 
tamanha quantidade de dados e tomar ações próativas em tempo hábil. O mesmo 
problema já vem sendo enfrentado hoje em dia com a análise desses mesmos dados  
em computadores. Porém, a disseminação da computação móvel só tende a 
agravar o problema. Para ajudar nessa tarefa de interpretação dos dados 
massivos gerados encontram-se as nuvens (\textit{clouds}). As nuvens habilitam 
que o processamento desses dados sejam delegados para a própria nuvem, e 
utilizados como serviços por computadores. Da mesma forma, a nuvem pode 
armazanar e agregar os dados coletados dentre as diversas vertentes de 
informações. Computação nas nuvens (\textit{Cloud Computing}) refere-se tanto 
para aplicações entregues como serviços através da Internet, quanto para o 
\textit{hardware} e sistemas de \textit{software} em \textit{datacenters} que 
proveem estes serviços \cite{armbrust:09}.

Embora, exista aplicativos móveis conectados na nuvem, como o Apple iCloud
\footnote{http://www.apple.com/icloud} e Google Gmail \textit{for Mobile}
\footnote{http://www.google.com/mobile/mail/}, estes aplicativos estão 
conectados a um servidor remoto responsável por toda a computação, tornando os 
dispositivos móveis apenas clientes finos (\textit{thin clients}). Todavia, 
estes aplicativos estão se tornando populares, mesmo que somente apresentem 
desempenho aceitável sobre conexeções de alta velocidade \cite{fernando:13}. 
Porém, alta velocidade de comunicação somado com alta disponibilidade de dados 
por um preço acessível e bom tempo de resposta na maioria dos lugares do mundo 
é inviável. De contra partida, comunicações de curto alcance consomem menos 
energia, tornando-se um fator chave um vez que dispositivos móveis geralmente 
operam com uma fonte de energia limitada. Somado a isso, conectar-se a 
recursos locais seria mais barato e ofereceria uma conectividade mais rápida 
com melhor disponibilidade de recursos. O autor \citetexto{satyanarayanan:09} 
explica que a internet móvel sem fios opera com uma largura de banda de 2 
Mbps, comparado com a largura de banda de 400 Mbps da WiFi LAN. Dependendo da 
interação do usuário, a latência pode variar significativamente. Como exemplo, 
uma latência de 80 ms contra 16 ms em uma imagem de 4 MB pode tornar um 
aplicativo inutilizavel e acabar com a experiência do usuário. Considerando a 
trajetória corrente de evolução da internet, embora a largura de banda esteja 
sujeita à melhorias, a latência não.

Portanto, considerando taxas de acesso a dados, problemas com latência e 
largura de banda, e a alta demanda de energia consumida pela conectividade 3G, 
a nuvem local móvel seria uma alternativa à nuvem remota \cite{satyanarayanan:09}. 
Nuvens móveis podem ser utilizadas para compartilhar recursos entre os 
dispositivos móveis, de forma a extender o poder computacional de um 
dispositivo e habilitar novos modos de operação que não eram possíveis. 
Voltamos para o conceito de internet da coisas, cujos dispositivos deverão 
estar interconectados. Através da nuvem móvel, dispositivos compostos por 
apenas identificadores e acesso ao meio de rede poderão compartilhar o uso de 
diferentes sensores contidos em dispositivos mais ricos em tecnologia.

O comércio é umas das áreas que mais carece de aplicações das tecnologias 
citadas acima. Uma pesquisa sobre a situação corrente da internet das coisas 
revela aplicações da computação ubíqua nas seguintes áreas de foco: 
transportes e logística, cuidados médicos, ambientes inteligentes, pessoal e 
social, e futuristas \cite{atzori:2010}. Os produtos poderiam ser inteligentes  
e estarem interligados com os dispositivos móveis dos consumidores, com o 
intuito de compartilhar informações relevantes sobre si mesmos de forma 
autônoma. Por se tratar de um modelo de negócio muito diversificado entre os 
praticantes, é difícil encontrar aplicativos que possam auxiliar no exercício 
e sucesso da atividade. Não obstante, o consumidor também não é beneficiado 
pelas tecnologias oferecidas pela computação da mesma forma que em outros 
sistemas. Por exemplo, no setor de logística, os usuários podem utilizar um 
serviço de rastreamento em tempo real oferecido pela empresa de transportes 
através da tecnologia de RFID.

Estes sensores devem naturalmente atender as mudanças de contexto aos quais 
estão inseridos e propagar decisões apropriadas \cite{xu:11}. Sistemas cientes 
do contexto requerem um exaustivo volume de comunicação para garantir que as 
informações de contextos sejam trocadas entre provedores e consumidores. Desta 
forma, para assegurar a interoperabilidade entre estes elementos, e gerenciar 
tais tecnologias, pode-se criar um \textit{middleware} que integre as 
tecnologias de redes móveis — 3G e 4G — com sensores RFID.

\section{Objetivo e Questão de Pesquisa}
Neste capítulo são apresentadas as questões de pesquisa deste trabalho bem 
como os objetivos que se pretende atingir com o seu desenvolvimento, 
subdividos em objetivo geral e objetivos específicos.

Após revisarmos as tendências da computação e o défict de aplicativos para o 
comércio em geral, sugere-se algumas reflexões: Como o RFID e as 
tecnologias de redes móveis podem ser integradas e utilizadas no comércio a 
fim de beneficiar seus praticantes? De que forma a internet das coisas poderia 
representar um papel significativo na construção de uma rede de informações 
globais entre comerciantes e consumidores? Como as nuvens móveis podem 
oportunizar novos serviços de forma autônoma aos consumidores?

Este trabalho tem como objetivo geral, a construção de uma aplicação para 
dispositivos móveis direcionada ao comércio eletrônico, que utilize a troca de 
informações entre sensores RFID e middleware de telefonia móvel, a fim de 
estabelecer uma rede sensível ao contexto de informações globais.

A partir do objetivo traçado, pode-se derivar os seguintes objetivos 
específicos que pretende-se atingir com o desenvolvimento da pesquisa:
\begin{itemize}
  \item Montar um estado-da-arte das tecnologias RFID, 3G e 4G;
  \item Elaborar um modelo para troca de informações sensoriais visando à ciência do contexto;
  \item	Implementar um middleware para utilização em aplicações para dispositivos móveis com as tecnologias citadas acima;
  \item Implementar um middleware para utilização em aplicações para dispositivos móveis com as tecnologias citadas acima;
  \item Testar a aplicação numa situação de comércio eletrônico.
\end{itemize}

\section{Organização do Texto}
%TODO Aguardando fechamento do formato do capitulos...

%=======================================================================
% Fundamentação Teórica
%=======================================================================
\chapter{Fundamentação Teórica}
TODO: Apresentar detalhes do que será tratado nas seções subsequentes da fundamentação teórica. Especificar que a seção não tem o objetivo de ser exaustiva e apenas contextualiza as tecnologias e conceitos dentro do tema proposto.

%=======================================================================
\section{Tecnologias para a Computação Móvel}
TODO: introduzir assunto sobre as tecnologias móveis

\subsection{802.11 e suas derivações}
Redes sem fio de área local (WLAN) são grupos de redes sem fio pertencentes a uma área geográfica limitada, como de um campus de universidade, escritórios de trabalho, e até mesmo casas, que podem se comunicarem através de rádio. Geralmente as WLANs são implementadas como extensões para as redes de área local (LAN) cabeadas, a fim de prover maior mobilidade ao acesso a rede por parte dos usuários \cite{nist:08}.

A seção a seguir tem o objetivo de descrever brevemente as variantes da tecnologia IEEE 802.11 mais utilizadas no mercado, juntamente com um histórico de evolução da tecnologia. Após são revisados os modelos de arquitura e os componentes básicos da rede. 

\subsubsection{Derivações do padrão 802.11}
As tecnologias envolvendo WLANs foram vistas pela primeira em 1990, quando fabricantes começaram a "produzir" produtos que operavam na frequência de banda de 900 MHz. Estas soluções utilizavam projetos proprietário sem nenhum padrão definido, e atingiam velocidades de transferência de aproximadamente 1 Mbps, que era consideralmente menor do que os 10 Mbps ofericidos pela tecnologia de LAN cabeada. Em 1992, fabricantes iniciaram a vender produtos a base de WLAN cuja frequência de operação era de 2,4 GHz. Embora, essa teconologia permitissem taxas de transferência maior que os produtos que operavam a 900 MHz, eles eram muito caros e ainda assim forneciam taxa de dados muito baixa e era muito sucetíveis a interferências externas de rádio.

Em 1990, a IEEE iniciou um projeto chamado IEEE 802.11 com o objetivo de 
desenvolver especificações de um controlador de acesso ao meio (MAC) e de uma camada física (PHY) para conectividade sem fios para estações fixa, portáveis e móveis em uma área \cite{nist:08}. O primeiro padrão internacional de interoperabilidade de WLANs, o IEEE 802.11, só veio a ser aprovado em 1997, cujo suporte limitava-se a três métodos de transmissão dentro da banda de 2,4 GHz. 

No ano de 1999 a IEEE ratificou duas emendas, IEEE 802.11a e IEEE 802.11b, que definiam métodos de transmissão de rádio e técnicas de modulação. Rapidamente os equipamentos WLAN que adotaram o padrão o IEEE 802.11b se tornaram dominantes no segmento de redes sem fio. Operando na banda de frequência de 2,4 GHz, o padrão oferecia taxa de dados de até 11 Mbps. O padrão IEEE 802.11b tinha o objetivo de melhorar o desempenho da rede, aumentar o \textit{throughput} de dados e adicionar mecanismos de segurança não encontrados nas LANs cabeadas. Já o padrão IEEE 802.11a operava na banda de frequência de 5,0 GHz, conhecida como Infraestrutura de Informações Nacionais Não licensiadas (UNII) podendo atingir uma tranferencia de dados de até 54 Mps. 

Em 2003, a IEEE liberou mais uma emenda, IEEE 802.11g, com o objetivo de especificar um método de transmissão que também suportasse a banda de frequência de 2,4 GHz, porém que permitisse atingir 54 Mbps de taxa de transmissão de dados e que fossem compatíveis com os produtos construídos sobre a IEEE 802.11b.

Alguns anos depois, em 2006, os primeiros rascunhos do padrão IEEE 802.11n foram apresentados, com a intenção de aumentar o alcance e melhorar a velocidade das WLANs para velocidades teóricas de 300 Mbps. Este novo padrão mantém retro compatibilidade com os padrões IEEE 802.11/a/b/g pois ele opera tanto em banda de frequência de 2,4 GHz como em 5,0 GHz. Por usar canais com banda maior, apresenta um \textit{throughput} bem mais elevado que seus predescessores, além de possuir equipamentos equipados com múltiplas antenas para aproveitar melhor o sinal RF, dobrando o alcançe da WLAN.

As variantes do padrão IEEE 802.11 até a versão IEEE 802.11n, todas possuem algumas primivitas de segurança, conhecidas coletivamente como \textit{Wired Equivalent Privacy} (WEP), no qual foram desenvolvidas para oferecer o mesmo nível de segurança de uma LAN cabada não encriptada. Porém diversos problemas de segurança com esta tecnologia já foram muito bem documentados. Desta forma, após o reconhecimento da gravidade dos problemas, a IEEE e a Wi-Fi Alliance se juntaram para criar soluções de curto e longo prazo para resolver estes problemas. Já no início de 2003, as duas entidades desenvolveram um sistema de segurança chamado \textit{Wi-Fi Protected Access} (WPA) para utilizar no lugar do WEP. Porém, o sistema foi desenvolvido em caráter de curto prazo para suprir a demanda atual até que uma medida mais robusta a logo prazo fosse criada. Em junho de 2004, a IEEE finalizou mais uma emenda entitulada 802.11i que foi desenhada para suprir todas as demandas e atendar as falhas encontradas na WEP, melhorando o WPA. O padrão IEEE 802.11i especifica um \textit{framework} de segurança que opera em conjunto com todos os outros padrões de tranmissão e modulação do sinal criados previamento e futuramente pela IEEE.

O padrão IEEE 802.11i inclui várias melhorias de segurança que mostra maturidade com a utilização de tecnologias de segurança já provadas. O padrão refere-se ao uso de \textit{Extensible Authentication Protocol} (EAP), que permite a autenticação mútua entre clientes de redes sem fios e a infraestrutura WLAN, bem como possibilita a distribuição automática de chaves criptográficas. Além do mais, o 802.11i permite o uso de práticas criptográficas já bem aceitas na academia, como a geração de \textit{checksums} critográficos através de \textit{hash message authentication codes} (HMAC). Este mesmo padrão apresenta o conceito de rede segura robusta --- \textit{Robust Security Network} (RSN). Redes RSN são restritas para RSNA --- \textit{Robust Security Network Associations} --- que reprentam uma conexão lógica entre entidades, conectadas através de IEEE 802.11, estabelecida por meio de um esquema de gerenciamento de chaves chamado \textit{4-Way Handshake}. O \textit{handshake} é um protocolo que: 
\begin{itemize}
\item valida se as duas entidades compartilharam uma chave mestra;
\item sincroniza a instalação de chaves temporais;
\item confirma a seleção e configuração dos protocolos de confidencialidade e integridade de dados.
\end{itemize}
A chave mestra, conhecida também como \textit{pairwise master key} (PMK), serve como base para os protocolos de confidencialidade e integridade dos dados, e é o grande diferencial na melhoria da segurança comparado a WEP utilizada nas versões primordiais do IEEE 802.11.

Também muito conhecido neste segmento de redes sem fio, é especificação WPA2. O WPA2 é uma especificação interoperável com o IEEE 802.11i criado pela \textit{Wi-Fi Alliance}.

A Tabela~\ref{tab:ieee80211} mostra um resumo das características das variantes do IEEE 802.11.

\begin{table}
	\caption{Comparação dos \textit{frameworks} de nuvens móveis}
	\label{tab:ieee80211}
	\centering%
	\begin{minipage}{\textwidth}
		\footnotesize
		\resizebox{\textwidth}{!} {
		\begin{tabular}{|c|c|c|l|}
			\hline
%           Header Line 1			
			\textbf{Especificação} & \textbf{Taxa de Dados} & \textbf{Banda de}   &
			\textbf{Comentários} \\
%			Header Line 2
			\textbf{IEEE}          & \textbf{Máxima}        & \textbf{Frequência} &
			                     \\
			\hline
%			Line 1
			802.11  &   2 Mbps & 2.4 GHz (ISM) & Tecnologia legada pouco utilizada \\
			\hline
%			Line 2
			802.11a &  54 Mbps & 5 GHz (UNII)  & Não compatível com IEEE 802.11b ou IEEE 802.11g \\
			        &          &               & Velocidade superior que \textit{10Base-T Ethernet} \\
			\hline
%           Line 3
			802.11b &  11 Mbps & 2.4 GHz (ISM) & Equipamentos baseados em IEEE 802.11b domínam a \\
			        &          &               & tecnologia WLAN \\
			        &          &               & Velocidade próxima de \textit{10Base-T Ethernet} \\	        
			        &          &               & Geralmente combinado com IEEE 802.11g oferencendo \\
			        &          &               & produtos compatíveis com IEEE 802.11b/g \\
			\hline
%			Line 4
			802.11g &  54 Mbps & 2.4 GHz (ISM) & Retro compatível com IEEE 802.11b \\
			        &          &               & Velocidade superior que \textit{10Base-T Ethernet} \\
			        &          &               & Suportado pela maioria dos dispositivos WLAN \\
			\hline
%			Line 5
			802.11n & 300 Mbps & 2.4 GHz (ISM) & Retro compatível com IEEE 802.11a/b/g \\
			        &          & e 5 GHz (UNII) &  Velocidade superior que \textit{10Base-T Ethernet} \\
			\hline
		\end{tabular}
		}
		\fonte{\citetexto{nist:08}}
	\end{minipage}
\end{table}

\subsubsection{Modelos de arquitetura e componentes de rede}
O padrão IEEE 802.11 tem dois componentes arquiteturais fundamentais:
\begin{itemize}
\item estações (STA): um STA é um dispositivo sem fio terminal, ou seja, está localizado em um ponto final da rede. Exemplos: \textit{laptops}, computadores, dispositivos móveis e outros dispositivos eletrônicos com base no IEEE 802.11;
\item pontos de acesso (AP): um AP connecta STAs logicamente com um sistema de distribuição, que é tipicamente uma infraestrutura cabeada. Os AP podem conectar logicamente STAs uns aos outros sem disponibilizar o acesso a qualquer sistema de distribuição. Os APs também possuem funcionalidade de operação em modo ponte, que permite aos APs integrarem duas redes distintas com a criação de 
uma rede ponto a ponto
\end{itemize}

A especificação IEEE 802.11 define duas topologias de rede básicas. A primeira, modo \textit{ad hoc}, não utiliza APs, somente STAs estão envolvidos neste modelo de comunicação. A segunda, modo infraestrutura, possui um AP que conecta os STAs entre si, ou ainda a um sistema de distribuição, tipicamente uma rede cabeada.

O modo \textit{ad hoc} é ilustrado no Figura~\ref{fig:wifiadhoc}. Este modo de operação, também  conhecido como modo \textit{peer-to-peer}, permite que dois ou mais STAs comuniquem-se diretamente uns com os outros. A Figura~\ref{fig:wifiadhoc} mostra três dispositivos sem fio comunicando-se entre si, sem a uma infraestrutura sem fios ou conexões cabeadas. Uma propriedade fundamental deste tipo de rede é que não definem mecanismos de desvios ou encaminhamentos de mensagens, portanto, todos os dispositivos devem estar dentro do campo de rádio uns dos outros.

Uma das vantagens chave das WLANs \textit{ad hoc} é que teoricamente elas podem formar-se a qualquer momento em qualquer lugar, permitindo à diversas pessoas criar uma conectividade sem fio barata, rápida e fácil com um \textit{hardware} mínimo. Na prática, a especificação IEEE 802.11 suporta vários tipos de diferentes de redes \textit{ad hoc}. Porém, os dispositivos clientes que operarem apenas em modo \textit{ad hoc} não podem comunicar-se com redes sem fios externas. Outra complicação é que a rede \textit{ad hoc} pode interferir na operação do modo infraestrutura baseado em AP que coexista no mesma banda de rádio.

O modo infraestrutura da especificação IEEE 802.11 compreende um conjunto de AP e um ou mais STAs. O AP é utilizado para conectar os STAs no serviço de distribuição. O serviço de distribuíção é o canal utilizado pelos STAs para comunicar-se com redes externas, como a Internet. A Figura~\ref{fig:wifiinfra} ilustra uma configuração em modo de infraestrura, contendo dois conjuntos de AP e STAs conectados a um serviço de distribuíção.

A utilização de múltiplos APs conectados a um único serviço de distribuíção permite a criação de rede sem fio de tamanho e complexidade arbitrário. Esta arquitetura permite que vários dispositivos, como \textit{laptops}, \textit{smartphones} e PDAs, acessem recursos na rede e a Internet. 

\subsection{3G e LTE (4G)}
Overview sobre redes móveis (livro wireless handbooks)

\subsubsection{3G}
Overview of Third Generation. (introduction to 3g mobile communication)
Breve historico, o q eh 3G, o que pede o standard

\subsubsection*{Standards}
- UMTS - 3GPP
- W-CDMA
- TD-SCDMA
- HSPA+
- CDMA2000

\subsubsection{4G}
find it...

\subsubsection*{Standard LTE}
find it...

\subsection{RFID}
Sistemas RFID são consistituídos fundamentalmente de quatro elementos: as 
\textit{tags} (etiquetas) RFID, os leitores RFID, as antenas e características 
de radio, e a rede de computadores utilizada para conectar os leitores
\cite{garfinkel:06}. A sessão a seguir está subdividida tal que aborde cada um 
dos elementos fundamentais de um sistema RFID citados acima.

\subsubsection{Tags}
A \textit{tag} é o elemento fundamental do RFID, conhecido como o alicerce do 
sistema. Cada \textit{tag} consiste de uma antena e um pequeno chip de 
sicilício contendo um receptor de radio, um modulador de radio frequência para 
transmitir a resposta de volta ao leitor, lógica de controle, uma memória e um 
sistema de alimentação. O sistema de alimentação pode ser completamente 
alimentado pelo sinal RF de entrada, sendo a \textit{tag} conhecida como 
\textit{tag} passiva. Existem também as \textit{tags} ativas que requerem uma 
fonte de alimentação, de modo que podem estar conectadas a uma infraestrutura 
de alimentação externa, ou utilizar a energia de uma bateria integrada à 
\textit{tag} \cite{want:06}.

As principais vantagens das \textit{tags} ativas sobre as passivas é o alcance 
se leitura e a confiança. Com uma antena apropriada em ambas extremidades ---  
no leitor e na \textit{tag} --- uma \textit{tag} de 915 MHz pode ser lida a 
uma distância de 30 metros. As \textit{tags} também tendem a serem mais 
confiáveis, uma vez que não necessitam de um sinal de radio contínuo para 
energizar seus componentes eletrônicos, evitando possíveis erros de leitura 
devido a descontinuidades do sinal de radio.

As \textit{tags} passivas, por sua vez, são bem menores em tamanho físico e 
bem mais baratas que as ativas, pois não apresentam o custo inerente das 
baterias. Outra vantagem é sua vida prolongada devido à ausência de bateria: 
enquanto a bateria de uma \textit{tag} ativa pode durar somente alguns anos, a 
\textit{tag} passiva pode, em princípio, ser lida durante muitas décadas após 
a fabricação do chip.

Existe ainda um tipo de \textit{tag} híbrida que combina as duas 
funcionalidades ativas e passivas, resultando em uma \textit{tag} de 
classificação intermediária semi-passiva. Estas \textit{tags} possuem bateria 
como as \textit{tags} ativas, ao passo que utilizam a força do leitor para 
transmitir uma mensagem de volta para o leitor RFID usando uma técnica 
conhecida como \textit{backscatter}. Logo, este tipo de \textit{tag} tem a 
confiabilidade de uma \textit{tag} ativa, porém com o alcançe de leitura da 
uma \textit{tag} passiva. O tempo de vida é superior ao tipo ativo, uma vez 
que a energia da bateria é utilizada apenas para alimentar o próprio circuito 
de leitura, e não a transmissão dos dados.

As \textit{tags} RFID podem ser de natureza promíscuas, de modo que aceitam a 
comunicação com quaisquer leitores, ou seguras, requerendo ao leitor fornecer 
uma senha ou outro tipo de credencial de autenticação antes da \textit{tag} 
responder. A grande maioria das \textit{tags} são implantadas de forma 
promíscua, não somente por serem mais baratas, mas também por facilitar o 
gerenciamento dos sistemas. Sistemas que empregam senhas ou códigos 
criptografados requerem que os códigos sejam distribuídos previamente e 
controlados apropriadamente, tornando-se um problema de gerenciamento muito 
complexo \cite{garfinkel:06}.

Os chips RFID mais simples contém somente um número serial, que consiste em um 
bloco de 64 bits ou 96 bits de armazenamento somente de leitura. Assim como o  
número serial pode ser queimado diretamente no chip pelo fabricante, é comum 
também encontrar chips programados em campo pelo usuário. Alguns chips irão 
aceitar somente um único código serial, enquanto outros permitem que o número 
serial seja alterado depois de gravado. Chips RFID mais sofisticados contém 
memória de leitura e escrita que podem ser programadas pelo leitor. Os chips 
RFID podem também possuir sensores, no qual o próprio chip tem a capacidade de 
gerenciar o armazenamento da medida do sensor na memória interna ou enviar 
estas informações coletadas dos sensores diretamente para o leitor.

As \textit{tags} RFID podem interferir umas nas outros. Quando múltiplas 
\textit{tags} estão presente no campo de ação de um leitor, o leitor pode ser 
incapaz de decifrar os sinais das \textit{tags}. Para as aplicações cujo 
sistema está otimizado de forma a ter somente uma \textit{tag} ao alcance em 
um determinado tempo, isso não é um problema. Como exemplo, pode-se citar a 
operação de uma cancela em um estacionamento, cuja existência de uma 
\textit{tag} é singular e limita-se específicamente a cada cancela. Por outro 
lado, para outras aplicações, a leitura de múltiplas \textit{tags} é 
essencial. Para estes casos, as \textit{tags} precisam suportar ou um 
protocolo anti-colisão ou um protocolo de fragmentação. Um protocolo de 
fragmentação permite que o leitor determine múltiplas \textit{tags} visíveis e 
itere sobre as elas, fazendo com que as \textit{tags} revezem suas respostas 
para o leitor, evitando a interferência de umas nas outras.

\subsubsection{Reader}
O leitor RFID envia pulsos de energia de rádio para a \textit{tag} e escuta a 
resposta de volta da \textit{tag}. A \textit{tag} detecta esta energia e envia 
de volta uma resposta contendo o seu número serial e possivelmente outras 
informações adicionais.

Em sistemas RFID simples, os pulsos de energia dos leitores funcionam apenas 
como uma chave liga-desliga. De contra partida, em sistemas mais sofisticados, 
o sinal RF (rádio frequência) do leitor pode conter comandos para as 
\textit{tags}, como instruções de leitura ou escrita na memória, e até mesmo 
senhas.

Historicamente, os leitores RFID foram construídos para a leitura de apenas um 
tipo em particular de \textit{tag}, porém os chamados leitores "multimodo" 
podem ler diferentes tipos de \textit{tags}, se tornando muito populares 
dentre os demais. Os leitores multimodo contribuem para a leitura promíscua 
das \textit{tags} e evitam que diversos dispositivos sejam necessários para 
processar um sistema de \textit{tags}.

Leitores RFID estão geralmente ligados, transmitindo sinais RF constantemente 
e aguardando alguma \textit{tag} entrar em seu campo de operação. Porém este 
modo de operação é indesejável em determinadas aplicações que possuem 
dispositivos alimentados por bateria e precisam economizar energia. Logo, é 
possível configurar um leitor RFID de forma que ele envie pulsos de rádio 
somente em resposta a algum evento externo. Por exemplo, a maioria dos 
sistemas de pedágios eletrônicos possuem leitores constantemente ligados de 
modo que cada carro que passe seja registrado. Por outro lado, RFID 
\textit{scanners} usados em escritórios veterinários são frequentemente 
equipados com gatilhos e os leitores são ligados apenas quando o gatilho é 
pressionado \cite{garfinkel:06}.

\subsubsection{Funcionamento}
O leitor de \textit{tag} é responsável por alimentar e comunicar com a 
\textit{tag}. A antena da \textit{tag} captura a energia e transfere o ID 
(número serial) da \textit{tag}. Este processo é controlado pelo chip 
integrado à \textit{tag} \cite{want:06}.

Existem duas abordagens de projeto fundamentais para a transferência de 
eneriga do leitor para a \textit{tag}: indução magnética e captura de ondas 
eletromagnéticas (EM) \cite{want:06}.

Estes dois modelos tiram vantagens das propriedades eletromagnéticas 
associadas com um antena RF, o \textit{near-field} e o \textit{far-field}. 
Através de várias técnicas de modulação, sinais baseados em \textit{near} e 
\textit{far field} podem também transmitir e receber dados \cite{finkenzeller:03}.

Acoplamento \textit{near-field} é a abordagem mais convencional para 
implementação de sistemas RFID passivos. Porém, a comunicação \textit{near-
field} tem algumas limitações físicas quanto a distância de operação e a 
energia disponível. Da mesma forma que a frequência de operação aumenta, a 
distância cujo acoplamento \textit{near-field} pode operar reduz 
\cite{want:06}. Outra limitação é quanto a energia disponível para a indução 
magnética, que por sua vez é uma função da distância do leitor.

\textit{Tags} RFID baseadas em emissões \textit{far-field} capturam as ondas 
eletromagnéticas propagadas da antena anexa ao leitor. Um leitor
\textit{far-field} típico pode interrogar \textit{tags} a três metros de 
distância com sucesso.

%TODO colocar figura que ilustra o near e far field

\subsection{EPCglobal}
O trabalho realizado pela EPCglobal foi uma peça chave para promover o uso de 
\textit{tags} UHF, quem tem sido a base das implementações mais populares da 
tecnologia em grandes empresas, como Wal-Mart e Tesco. A EPCglobal 
originalmente se chamava MIT \textit{Auto-ID Center}, uma organização sem fins 
lucrativos criada pelo MIT \textit{Media Lab}. O centro foi posteriormente 
divido em duas partes: o \textit{Auto-ID labs}, ainda parte do MIT, e a 
EPCglobal, uma empresa comercial \citep{want:06}. 

A visão do \textit{Auto-ID Center} era criar um "mundo inteligente" através de 
uma infraestrutura inteligente que conectasse objetos, informações e pessoas 
por meio de uma rede ubíqua de computadores. A criação desta infraestrutura 
inteligente demandou a habilidade de poder identificar automaticamente e 
unicamente os objetos. Interligados com núcleo da infraestrutura provida pelo 
sistema de computação ubíqua, o mecanismo de identificação alavancaria a 
Internet para uma conectividade global \cite{ranasinghe:10}. Os componentes 
que formam a infraestrutura inteligente são comumente referidos como uma rede 
EPC (\textit{EPC Network}), no qual o termo EPC (\textit{Electronic Product 
Code}) --- código eletrônico de produto --- é um esquema de identificação 
única de um objeto empregado pelo sistema. 

\subsubsection{Arquitetura}
A arquitetura da rede EPC continua a evoluir agregando novas tecnologias desde 
seu início. Inicialmente, o Auto-ID Center desenvolveu a rede sobre uma 
arquitetura baseada em componentes, porém, versões mais recentes baseiam-se em 
uma arquitetura em camadas orientada a serviços com êmfase na definição de 
interfaces \cite{epcg:nfa:05}. As interfaces definem as funcinalidades padrões 
e métodos de acesso às funcionalidades, ao invés de definirem os próprios 
componentes e suas funcionalidades como foi inicialmente concebido. Dentre as 
vantagens de tal arquitetura, está a modularização do software e a 
padronização de interfaces, permitindo que diferentes fabricantes criem seus 
produtos. A definição de interfaces, além de facilitar o processo de 
certificação de confirmadade de acordo os padrões estabelecidos, ainda permite 
a definição do modelo de dados e métodos em níveis abstratos. Desta forma, as 
interfaces podem ser facilmente descritas com a utilização de tecnologias XML 
ou WSDL.

A abordagem de arquitetura em N-camadas orientada a serviço se encaixa 
naturalmente em uma modelagem orientada à objetos, pois os objetos encapsulam 
informações e estado ao passo que oferecem funcionalidades através de suas 
interfaces. Os módulos possuem também acoplamento solto dada a independência 
dos diferentes módulos. Esta redução de dependência também facilita o 
gerenciamento e a extendibilidade do sistema. Muitos dos conceitos utilizados 
nesta arquitetura vem de uma arquitetura conceitual chamada SOA 
(\textit{service-oriented architecture}) \cite{epcg:nfa:05}.

\subsubsection{Rede EPC}
A rede EPC pode ser descrita como uma infraestrutura ubíqua inteligente que 
interliga objetos físicos com a iternet automaticamente. A rede de objetos 
físicos é obtida com a integração de uma \textit{tag} a um objeto. O sistema 
interage com os objetos comunicando-se com os mesmos através de interrogadores 
dispostos em locais apropriados. Os leitores (interrogadores) coletam os dados 
dos objetos, identificados com \textit{tags} RFID, que retornam um código EPC 
de volta para o leitor, identificando-se assim como objetos únicos na rede 
\cite{ranasinghe:10}.

A Figura~\ref{fig:ovrEPCNet} ilustra os componentes que consituem a rede EPC. 
As flechas tracejadas indicam o fluxo de dados a partir das \textit{tags} para 
o sistema de suporte a rede, enquanto que as flechas contínuas indicam o fluxo 
de comandos e dados de volta para os leitores e \textit{tags}. A parte grifada 
em cinza com bordas tracejadas é local para uma única organização.

\begin{figure}
	\caption{Visão Geral de uma rede EPC. }
	\label{fig:ovrEPCNet}
	\centering%
	\begin{minipage}{\textwidth}
		\includegraphics[width=\textwidth]{Figuras/ovrEPCNet}
		\fonte{Adaptado de \citetexto{ranasinghe:10}}
	\end{minipage}
\end{figure}

Em sistemas de redes RFID, os leitores detectam certos eventos automaticamente 
ou podem interrogarem as \textit{tags} a fim de obter dados sobre eventos para 
posteriormente encaminhar as informações resultantes para aplicações do 
sistema. As aplicações do sistema respondem aos eventos, que processam ações 
correspondentes, como a criação de ordens de compra para produtos adicionais, 
o envio de avisos de alerta de furto, o acionamento de alarmes por causa de 
elementos químicos pergigosos, ou informar sobre a troca de componentes 
frágeis antes que venham a falhar.

A rede EPC pode ser divida em seis módulos primários, alguns físicos outros 
lógico: \textit{tags} RFID, leitores RFID, EPC, um \textit{middleware} de 
filtragem de dados com suporte a interface de eventos em nível de aplicação 
(ALE), serviço de nome de objetos (ONS), e um serviço de informações EPC 
(EPCIS) \cite{ranasinghe:10}.

A rede EPC ilustrada na Figura~\ref{fig:ovrEPCNet} é uma rede EPC local, ou 
seja, presa a uma LAN. Esta arquitetura é frequentemente encontrada em 
empresas, organizaçãoes ou redes privadas. Logo, os dados coletados dentro de 
uma organização privada podem serem centralizados por meio de um EPCIS local à 
organização. Entretanto, a arquitetura foi construída para suportar o 
gerenciamento de informações distribuídas decentralizadas. Para alcançar este 
objetivo, a rede EPC interconecta redes EPC locais através do 
\textit{backbone} na Internet. O resultado desta ligação é uma rede EPC de 
longo alcance, que conta com um fluxo de informações e dados globais. Esta 
arquitetura WAN possibilita a troca de informações entre organizações no nível 
de objetos unicamente e individualmente identificados. Essa característica 
proporciona a extração de informações de ciclo de vida de um objeto, cujas 
informações podem estar fragmentadas por muitas organizações ao invés de 
integrar apenas um banco de dados centralizado.

A Figura~\ref{fig:ovrWANEPCNet} ilustra uma arquitetura de longo alcance, no 
qual várias redes EPC locais podem serem interligadas através de um ONS 
central conectado com um serviço de descobrimento.

\begin{figure}
	\caption{Visão Geral de uma rede EPC de longo alcance.}
	\label{fig:ovrWANEPCNet}
	\centering%
	\begin{minipage}{\textwidth}
		\includegraphics[width=\textwidth]{Figuras/ovrWANEPCNet}
		\fonte{Adaptado de \citetexto{ranasinghe:10}}
	\end{minipage}
\end{figure}

Tanto a EPCglobal quanto o \textit{Auto-ID labs} estão colaborando 
efetivamente para formalizar padrões para as interfaces mostradas na Figura~
\ref{fig:ovrWANEPCNet}. O objetivo é conseguir interoperabilidade entre 
diferentes serviços e habilitar fornecedores de software e hardware à suprir a 
demanda de tecnologias e equipamentos para o estabelecimento de redes EPC. A 
Figura~\ref{fig:intEPCNet} mostra as interfaces que já foram padronizadas pela 
EPCglobal e podem ser encontradas em \citetexto{epcglobal}.

\begin{figure}
	\caption{Arquitura de uma rede EPC mostrando as interfaces já padronizadas.}
	\label{fig:intEPCNet}
	\centering%
	\begin{minipage}{\textwidth}
		\includegraphics[width=\textwidth]{Figuras/intEPCNet}
		\fonte{Adaptado de \citetexto{ranasinghe:10}}
	\end{minipage}
\end{figure}

\subsubsection{Componentes RFID}
A arquitetura da rede não impõem nenhuma restrição sobre os tipos de 
\textit{tags} que podem ser empregadas. \textit{Tags} que apresentam 
funcionalidades a mais, acabam enriquecendo a camada de aplicação. O protocolo 
de interface de ar que domina o mercado atualmente é o \textit{Class I 
Generation 2} ratificado pela EPCglobal. Este protocolo foi aceito como um 
padrão da ISO, ISO18000-6 \textit{Type} C, juntamente com os demais protocolos 
de interface de ar definidos nos padrões ISO 18000 \cite{ranasinghe:10}.

O identificador de objetos deve ter escopo global que seja capaz de 
identificar todos os objetos unicamente. Todavia, o identificador servirá como 
um ponteiro para o local onde as informações sobre o objeto e as 
funcionalidades da \textit{tag} estarão armazenadas ao longo da rede. O código 
eletrônico de produto (EPC) é um esquema projetado para a identificação 
universal de objetos de acordo com os padrões desenvolvidos pela EPCglobal.

O formato do identificador único, definido como EPC, é uma estrutura de dados 
flexivível que suporta uma grande quantidade de esquemas de identificação 
legados ainda muito utilizados atualmente. Não obstante, o \textit{framework} 
flexível disponibilizado pelo EPC permite que organizações integrem formatos 
de númeração baseado suas próprias normas.

\subsubsection{Eventos de nível de aplicação}
Os \textit{middlewares} de filtragem são utilizados para prover processamento 
em tempo real dos dados de eventos das \textit{tags}. Os eventos de nível de 
aplicação (\textit{Application Level Events)} --- ALE --- fornecem um 
mecanismo padrão de requisição de dados de eventos. Conceitualmente, o 
\textit{middleware} de filtragem ocupa o espaço entre os leitores e 
repositório de eventos.

O \textit{middleware} recebe as requisições diretamente das aplicações, 
processa os dados dos leitores e retorna os identificadores únicos das 
\textit{tags}. Essa resposta pode ser pertinente tanto para as aplicações 
requerentes, como para outros sistemas, quando especificado na requisição. Os 
dados EPC são reportados como eventos através da interface ALE, e são 
estruturados como "quais", "onde" e "quando" os EPCs foram visitados.

Estes \textit{middlewares} possuem várias funções fundamentais, tais quais 
incluem a filtragem dos dados da \textit{tag} recebida, agregação e contagem 
dos dados de uma \textit{tag} e acumulação temporária de dos dados por um 
determinado período de tempo. A retenção de longo prazo dos eventos não é uma 
função esperada de um \textit{middleware} de filtragem. Sem estas funções nos 
\textit{middlewares}, não seria possível manipular grandes quantidades de 
dados geradas por um sistema RFID quando há o interrogatório constante das 
\textit{tags}. A interface ALE, por exemplo, permite que aplicações locais 
especifiquem a significância dos dados obtidos das \textit{tags} RFID. A 
Figura~\ref{fig:aleEPC} mostra uma arquitetura conceitual do 
\textit{middleware} de filtragem.

\begin{figure}
	\caption{Arquitura do middleware a suas interações com componentes da rede EPC, EPCIS e leitores.}
	\label{fig:aleEPC}
	\centering%
	\begin{minipage}{\textwidth}
		\includegraphics[width=\textwidth]{Figuras/aleEPC}
		\fonte{Adaptado de \citetexto{ranasinghe:10}}
	\end{minipage}
\end{figure}

O gerenciamento de eventos também é um dos principais serviços oferecidos 
pelos \textit{middlewares} de filtragem. A função mais comum no gerenciamento 
de eventos é a que dá nome ao \textit{middleware}: a filtragem, que é muito 
útil para situações onde existe tráfego de dados intenso. Por exemplo, 
dependendo da configuração dos leitores, um leitor pode ler dados de várias 
\textit{tags} repetidamente, porém nem todos as \textit{tags} lidas são de 
interesse da aplicação. O processo de filtragem dos dados permite eliminar 
informações que são redundantes, ou que não foram requeridas pela aplicação. 
Além do mais, eventos ALE podem ser constituídos por diferentes conjuntos de 
identificadores, gerando eventos específicos quando determinado identificador 
é visto pela primeira vez (chegada do item ao estoque) ou quando ele não é 
mais visto após certo tempo (saída do item do estoque) \cite{ranasinghe:10}.

O EPC serve apenas como referência para a informação, logo, o armazenamendo, 
transporte e descrição desta informação requer uma estrutura universal que 
possa ser compreendida, e transportada através da Internet. O \textit{Auto-ID 
center} caracterizou duas instâncias como sua estrutura universal: ECSpec 
(\textit{Event Cycle Specificaion}) e ECReports (\textit{Event Cycles 
Reports}) ambas utilizando XML. Portanto requisições para o 
\textit{middleware} são enviadas como objetos ECSpec, enquanto os dado são 
retornados como objetos ECReports. Os dados dos eventos reportados podem ser 
filtrados de acordo com regras do cliente, como identificador da empresa, tipo 
de objeto ou unidade logistica.

\subsubsection{Serviço de nomes de objetos}
As funcionalidades providas pelo serviço de nome de objetos (ONS) são 
similares aos serviços oferecidos pelo DNS (Domain Name System). Porém, ao 
invés de traduzir endereços de internet (\textit{host names}) para seus 
respectivos endereços IP, o ONS traduz um EPC para URL(s)\cite{ranasinghe:10}. 
O serviço de nomes de ojetos de uma rede EPC identifica uma lista de serviços 
oficiais associadas com o EPC, e não fornece nenhum dado real relativo a um 
determinado EPC. Serivços oficiais são aqueles cuja entidade que controla as 
informações sobre o EPC, armazenadas no ONS, é a mesma entidade que colocou o 
EPC no produto. Isso implica que o ONS aponte apenas para informações de 
serviços oferecidos pelo próprio fabricante. A especificação ONS versão 1.0 
não prove registros diferenciados para cada EPC, mas sim, fornece registros 
para uma classe de objetos ou tipo de produto. É importante notar também, que 
o ONS não fornece múltiplas URLs para informações de diferentes provedores 
dentro do ciclo de vida de um produto.

O ONS pode ser visto como um diretório de telefonia reverso, uma vez que o ONS 
utiliza um número (EPC) para retornar a localização dos dados do EPC de sua 
base de dados. O ONS é baseado no já consolidado DNS, desta forma, para 
facilitar a utilização do ONS, foi utilizado o mesmo padrão especificado para 
o DNS (RFC 1034: \textit{Domain names, Concepts and facilitiies}) durante o 
acesso e retorno das informações. Especificamente, o ONS utiliza um tipo de 
registro do DNS, chamado NAPTR (Naming Authority Pointer) a fim de fornecer, 
futuramente, maior flexibilidade para as consultas ao ONS. O NAPTR permite o 
uso de expressões regulares, ou seja, futuramente as respostas fornecidas pelo 
ONS atendarão à padrões. Os resultado de uma consulta serão endereços URL que 
contenham o número serial como parte da URL, sem a necessidade de adicionar um 
novo registro no ONS para cada número serial de um produto. Porém, o ONS nunca 
irá apontar diretamente para um endereço IP, tal funcionalidade é pertinente 
para o DNS, que continua sendo utilizado para resolver endereços \textit{web}.

A Figura~\ref{fig:onsEPCNet} ilustra uma visão geral de um sistema ONS: as 
informações associadas ao EPC são obtidas partindo do EPC codificado em uma 
\textit{tag}, capturado pelo leitor RFID, passando pela resolução do EPC 
através de uma consulta ao ONS local.

\begin{figure}
	\caption{Visão geral da funcionalidade de um sistema ONS.}
	\label{fig:onsEPCNet}
	\centering%
	\begin{minipage}{\textwidth}
		\includegraphics[width=\textwidth]{Figuras/onsEPCNet}
		\fonte{Adaptado de \citetexto{ranasinghe:10}}
	\end{minipage}
\end{figure}

A URL armazanada no ONS pode indicar diretamente um servidor que contenha um 
serviço (\textit{web server} com párginas de internet específicas do produto) 
ou pode apontar para o endereço de um descritor de serviços \textit{web} 
(WSDL). Este descritor de serviço pode ainda conter outros redirecionamentos 
para serviços mais especializados, como um EPCIS. Desta forma o ONS não 
resolve buscas profundas até o nível de serialização do EPC. A cobertura da 
pesquisa limita-se ao nível de classe de objeto. Logo, buscas relativas a 
números seriais dos produtos devem ser direcionadas para os serviços obtidos 
através do ONS. Uma proposta para este tipo de serviço são os EPC 
\textit{Discovery Services}, ainda não padronizados.

\subsubsection{Serviço de informações EPC}
Os serviços de informações EPC (EPCIS) são portas acesso entre os requerentes 
de informações e a base da dados que contém as informações. As consultas são 
respondidas em um formato padrão, porém o armazenamento interno dos dados na 
base de dados pode ser em qualquer formato ou padrão. O EPCIS funciona como um 
interprete da comunicação entre as aplicações e a base de dados, fornecendo 
aos demais componentes da rede EPC uma interface padrão de acesso as 
informações. Também é possível encontrar implementações de EPCIS que não 
contenha forma de armazenamento, no qual os serviços oferecidos são os atuais 
agrupamentos de eventos processados pelos leitores.

Os EPCIS possuem uma interface padrão defina pela EPCgloabal, e podem também 
serem implementados por meio de tecnologias de \textit{web services}. Nesse 
contexto, os \textit{web services} habilitam que aplicações em uma WAN 
utilizem os serviços providos por um serviço de informações EPC local. A 
Figura~\ref{fig:onsEPCIS} ilustra a comunicação entre os sistemas EPCIS, 
implementado baseado em \textit{web services}, ONS e aplicações externas.

\begin{figure}
	\caption{Interação entre EPCIS, ONS e aplicações externas.}
	\label{fig:onsEPCIS}
	\centering%
	\begin{minipage}{\textwidth}
		\includegraphics[width=\textwidth]{Figuras/onsEPCIS}
		\fonte{Adaptado de \citetexto{ranasinghe:10}}
	\end{minipage}
\end{figure}

Informações sobre um EPC em particular podem estar distribuídas entre um 
grande número de redes locais. Por exemplo, em um sistema de cadeia de 
suprimentos, o objetos deverá passar por vários locais físicos, tais como 
fabricantes, distribuidores, e revendedores. Porém, não é responsabilidade do 
ONS resolver buscas em nível do número serial do EPC, e sim do serviço de 
descobrimento (EPC-DS).

O EPC-DS pode ser melhor descrito como um motor de busca para dados relativos 
ao EPC \cite{epcg:ecpis:07}. Desta forma, o EPC-DS possui funcionalidades para 
os portadores de uma \textit{tag} RFID em particular atualizar as informações 
no EPC-DS, a fim de indicar que eles também possuem informações relativas à um 
EPC. Um registro de um EPC-DS pode conter uma lista de URLs de EPCIS, onde as 
informações sobre o produto poderão finalmente serem obtidas. Ao contrário do 
ONS, os registros contidos no EPC-DS não são oficiais, uma vez que outras 
organizações que participaram do ciclo de vida do produto podem adicionar 
informações adicionais. 

Portanto, o EPC-DS é uma adição ao ONS, que possibilita buscas em nível de 
número serial de um EPC. A raiz do ONS aponta em primeira instância para os 
serviços de informações do fabricante, e possivelmente para um EPC-DS que 
contenha informações sobre este EPC. Complementando o sistema, o EPC-DS provê 
diversos endereços para redes EPC locais por onde o produto tenha passado. 

\subsection{NFC}
Com início em 2002, a Philips\footnote{http://www.philips.com} foi a pioneira 
na discussão de um padrão aberto através da \textit{EMCA International}, que 
resultou no \textit{Near-Field Communication Forum} (NFC).

O fórum foi criado com a intenção de integrar sinais ativos entre dispositivos 
móveis utilizando acoplamento \textit{near-field}, com a utilização de 
abordagens de leituras compatíveis com os produtos RFID passivos já 
existentes. O novo padrão NFC tem como foco prover um mecanismo em que 
dispositivos móveis sem fio possam se comunicarem com outros dispositivos nas 
imediações locais de até vinte centímetros, ao invés de dependerem de 
mecanismos de descoberta utilizados em padrões de rádio de curto alcance. Tais 
padrões, como Bluetooth e WiFi, possuem características de propagação 
imprevisíveis e acabam por formar associações com dispositivos que podem não 
serem locais a rede \cite{want:06}.

O padrão NFC tem como objetivo simplificar o processo de descobrimento de 
dispositivos. Isto se dá por meio da passagem de endereços de controladores de 
acesso de mídia (\textit{Media Access Control}) e chaves em canais 
criptografados entre sinais de rádio. Tais sinais de rádio trafegam através de 
um canal lateral de acoplamento \textit{near-field}, que quando limitado a 20 
centímetros de distância, permite que usuários utilizem a segurança intrínseca 
da proximidade física para a troca de chaves criptográficas \cite{want:06}.

O forum deliberadamente projetou o padrão NFC para ser compatível com as 
\textit{tags} RFID que seguem o padrão ISO 15693 operando em uma banda de 
13,56 Mhz. Além disso, também tornaram os dispositivos móveis aptos à 
interrogar este popular padrão de \textit{tags}.

Atualmente existem várias aplicações utilizando a tecnologia NFC, tais como 
serviços de pagamento, serviços de ingressos, sistemas de gerenciamento de 
cadeia de suprimentos e novas aplicações específicas tem aparecido, como os 
cartazes inteligentes (\textit{smart posters}) \cite{ok:10}.

Uma complicação para adoção massiva do padrão NFC é que as \textit{tags} RFID 
utilizadas pela EPCglobal são baseadas em técnicas de comunicação
\textit{far-field}, operando em frequências UHF. Desta forma, os padrões NFC e 
EPCglobal tornam-se fundamentalmente incompatíveis \cite{want:06}.

\subsubsection{Funcionamento}
A comunicação acontece quando dois dispositivos compatíveis com o padrão NFC 
são aproximados por uma distância de aproximadamente quatro centímetros, 
dependendo muito do dispositivo em questão, ou simplesmente enconstnado um ao 
outro. A comunicação NFC opera a 13,36 MHz e pode transferir dados em até 424 
Kbs.

No modelo NFC, dois dispositivos estão envolvidos na comunicação, que são 
chamados iniciante (\textit{initiator}) e destino (\textit{target}). O 
\textit{initiator} é um dispositivo NF ativo, cuja responsabilidade é iniciar 
a comunicação e fornecer a energia necessária para a comunicação. Já os 
\textit{targets}, podem ser tanto uma \textit{tag} RFID simples, como um RFID 
card ou até mesmo um dispositivo NFC que responda às requisições do 
\textit{initiator} \cite{ok:10}.

Os dispositivos que fazem parte da comunicação compartilham a mesma banda RF, 
cuja comunicação é \textit{half-duplex}. Quando um dispositivo está 
transmitindo, o outro deve primeito escutar a transmissão, e somente deve 
iniciar à transmitir seus dados após ter acabado transferência do dispositivo 
que iniciou a comunicação \cite{ok:10}.

\subsubsection{Modos de Operação}
NFC possui três modos de operação: Leitor/Escritor (\textit{Reader/Writer}), 
Ponto a ponto (\textit{Peer-to-Peer}), e \textit{Card Emulation}. No modo 
\textit{Reader/Writer} os dados são transferidos da \textit{tag} NFC para o 
dispositivo móvel ou do dispositivo móvel para a \textit{tag} NFC. No modo de 
\textit{card emulation}, os dados são transferidos de um dispositivo móvel 
para um leitor NFC. Por fim, no modo \textit{Peer-to-Peer} os dados são 
transferidos entre dois dispositivos compatíveis NFC. A seguir, cada um dos 
modos de operação serão detalhados quantos as suas caracteristicas.

Modo \textit{Reader/Writer}: os dispositivos NFC podem ler e gravar dados nas 
\textit{tags} NFC. Os dispositivos atuam como \textit{initiators} e as 
\textit{tags} passivas são os \textit{targets}. As \textit{tags} não 
necessitam de nenhuma fonte de alimentação, visto que os dispositivos criam um 
acoplamento magnético indutivo para transferir a energia à \textit{tag} quanto 
ela estiver em uma distância próxima. Assim que a \textit{tag} é alimentada a 
comunicação inicia-se. Nest modo de operação a velocidade da troca de dados 
pode alcançar até 106 Kbps.

Modo \textit{Card Emulation}: um dispositivo NFC atua como um cartão RFID, e 
outro dispositivo NFC pode ler dados deste dispositivo. A vantagem deste modo 
é que não há a necessidade de nenhuma \textit{tag} NFC ou cartão RFID, e as 
informações armazenadas no dispositivo NFC são utilizadas para demais 
operações.

Modo \textit{Peer-to-Peer}: dois dispositivos podem compartilhar dados 
diretamente em nivel da camada dois do modelo OSI (\textit{link}). Esta 
propriedade da comunicação P2P, habilita aplicações à utilizarem NFC para o 
pareamento de dispositivos. Este modo é padronizado pelo padrão ISO/IEC 18092 
e possibilita velocidade de dados de até 424 Kbps.

%=======================================================================
\section{Internet das Coisas}

A internet das coisas (IoT) é a integração discreta do mundo físico com o mundo 
digital, no qual coisas provem suas funcionalidades como serviços do mundo 
real. Estes serviços promovem a interação e comunicação do ambiente com outras 
coisas através da troca de dados e informações capturadas sobre o ambiente. Os 
elementos da Internet das Coisas reagem de forma autônoma aos eventos do mundo 
físico, influenciando-o pela execução de processos, que engatilham ações e 
criam serviços com ou sem a intervenção direta do homem \cite{wei:12}.

O nome "Internet das Coisas" pode ser atribuído ao \textit{The Auto-ID Labs} [4], uma rede de laboratórios globais voltados para a pesquisa acadêmica na área de RFID conectados à rede e tecnologias sensoriais emergentes \cite{atzori:2010}.
As seguintes subseções abordam as diferentes visões sobre internet das coisas encontrada na literatura, aprofundando o foco principal de cada uma das visões, e a seguir são apresentados alguns problemas já salientados que ainda não foram explorados.

\subsection{Visões de Internet das Coisas}
O termo internet das coisas é muitas vezes nebuloso para muitos autores. Ele é sintaticamente composto por dois termos: o primeiro tende à uma visão orientada a rede da IoT, enquanto o segundo sugere um foco em objetos genéricos que podem serem integrados em um \textit{framework} comum. Na verdade, o termo Internet das coisas semanticamente significa "uma rede global de objetos interconectados unicamente endereçáveis, baseada em protocolos de comunicação padrões". [3] O que significa um grande número de dispositivos heterogêneos envolvidos no processo. O endereçamento único dos objetos e a representação e armazenamento de informações compartilhadas tornam-se os problemas mais desafiadores, levando diretamente a um terceiro paradigma da IoT: orientado à semântica.

O paradigma da internet das coisas é tratado de três formas na literatura:

\begin{itemize}
  \item Uma visão orientada a coisas, no qual o foco de atenção dos estudos são tecnologias que possibilitam o endereçamento e rastreamento dos objetos;
  \item Uma visão orientada à internet (rede), cujo foco é o acesso aos objetos de qualquer lugar a qualquer momento;
  \item E uma visão orientada à semântica, em que problemas de representação, busca e organização dos dados são tratados.
\end{itemize}

A primeira definição de IoT deriva de uma visão orientada à coisas. As "coisas" constituem itens bem simples tecnologicamente: RFID \textit{tags}. Sem dúvidas é uma abordagem chave no caminho para a adesão da Internet das Coisas, porém não é a única.

Generalizando, a IoT não poderá ser constituída apenas por um sistema EPCglobal, em que todos os objetos são RFIDs. Segundo (6), iniciar com soluções centradas em RFID é positivo, uma vez que os principais aspectos estressados pela tecnologia, rastreamento e endereçamento de itens, devem definitivamente ser endereçados também pela IoT. Porém o próprio nome IoT reconhece uma visão maior, e de alguma forma mais completa, do que a ideia de meros objetos identificados.

Acredita-se que o RFID ainda seja a tecnologia de ponta encabeçando a visão, devido a sua maturidade, baixo custo e forte apoio do mercado [7]. O autor ainda assegura que existe uma vasta gama de dispositivos, redes e serviços que também irão eventualmente compor a IoT. Tecnologias como NFC e \textit{Wireless Sensor and Atuator Networks} (WSAN) juntamente com o RFID são reconhecidas como os componentes atômicos que irão conectar o mundo real com o mundo digital.

Deve-se também mencionar a visão orientada à semântica encontrada na literatura. A ideia proposta por ela é que o número de itens envolvidos na internet do futuro é destinado a se tornar extremamente grande. Desde modo, problemas relacionados com a representação, armazenamento, interconexão, busca e organização da informação gerada pela IoT irão se tornar desafiadores. Neste contexto, tecnologias semânticas seriam peças chave. Elas poderiam ser utilizadas para explorar soluções de modelagem apropriadas para descrever coisas, raciocínio sobre os dados gerados, ambientes de execuções semânticas e arquiteturas que acomodassem os requerimentos da IoT, com armazenamento escalável e infraestrutura de comunicação [14].

A Figura~\ref{fig:iot} ilustra o paradigma da IoT como uma convergência das três visões destacadas, juntamente com algumas tecnologias que habilitam cada umas das visões.

\subsection{Problemas a serem explorados}
Por mais que as tecnologias propostas para a IoT tornam sua implementação viável, um grande esforço de pesquisa ainda é requirido na área. O autor \citetexto{atzori:2010} apresenta alguns pontos que, mesmo com algumas frentes já trabalhando para soluções, não existe um concenso ou maturidade em suas propostas, deixando os problemas ainda à serem explorados:

\begin{itemize}
\item \textbf{padronização}: várias contribuições para a padronização da IoT estão sendo propostas pela comunidade acadêmica. Existe uma ideia emergente em considerar a padronização da IoT como parte integral da definição da Internet futura. Porém, mesmo com diferentes frentes propondo novos padrões, é importante mencionar que as organizações estão colaborando ativamente com outras organizações, grupos de interesse e alianças. A IPSO, a ZigBee Alliance,  a IETF e a IEEE estão trabalhando na mesma direção para integrar o padrão IP;

\item \textbf{suporte a mobilidade}: a IoT irá agregar uma grande quantidade de nodos, cujo cada nodo produzirá conteúdos que devem ser acessados por qualquer usuário autorizado independentemente de sua localização. Isto requer políticas de endereçamente muito efetivas, porém atualmente o protocolo IPv4 está ficando saturado e sua disponibilidade rapidamente cessará. Soluções que utilizam IPv6 já foram propostas para os nodos, porém, os endereços são expressos em 128 bits, e as \textit{tags} RFID mais comuns utilizam identificadores de apenas 96 bits. Apesar se já existirem algums propostas para lidar com o endereçamento, nenhuma das soluções considera o suporte a mobilidade. O sistems como um todo será composto por vários subsistemas com características diferentes. Soluções já foram propostas exclusivamente para gerenciamento de mobilidade, porém, sua viabilidade perante a IoT devem ser novamente testados, pois podem haver problemas em termos de escalabilidade e adaptabilidade dada heterogeidade do ambiente;

\item \textbf{serviço de nomes}: na Internet tradicional \textit{hostnames} podem ser identificados através da consulta ao DNS. O objetivo do DNS é retornar o endereço IP de dado \textit{hostname}. Entretanto, o conceito de servidor de nomes de objetos (ONS) precisa introduzido, cuja função é associar uma referência à uma descrição de um objeto específico e sua \textit{tag} RFID relacionada. De fato, uma \textit{tag} RFID é mapeada para uma URL, que aponta para informações relevantes sobre o objeto. Na IoT, o ONS deve operar em ambas direções permitindo tanto associar a descrição de um objeto específico para uma \textit{tag} RFID identificadora como o contrário. Inverter a funcionalidade de operação do ONS não é trivial e requer um serviço específico, chamado serviço de mapeamento de códigos de objetos (OCMS). Da mesma forma que a mobilidade, algumas propostas utilizando P2P já foram concebidas, porém não foram analisadas em ambiente operacionalmete complexos, como a IoT;

\item \textbf{protocolos de transporte}: um dos principais objetivos da camada de transporte é assegurar a confiabilidade ponto a ponto e executar um controle de congestionamento também ponto a ponto em uma rede. Na internet tradicional, o protocolo utilizado para garantir confiabilidade na camada de transporte é o TCP, cujas características de operação são inadequado para IoT. O TCP torna-se inviável por apresentar uma inicialização de conexão pesada com o procedimento de três \textit{handshakes}, um controle de congestionamento de tráfego que causaria problemas de desempenho nas comunicações e \textit{buffer} de dados cuja gerencia é custosa considerando equipamento alimentados por bateria. Até então, nenhuma solução foi proposta para tratar este problema na IoT.

\item \textbf{caracterização de tráfego e QoS}: a caracterização do tráfego também na IoT também não é conhecida ainda para o desenvolvimento de infraestruturas de rede e protocolos. Sabe-se que as características de trafego em rede se sensores sem fios dependem fortemente de cenários da aplicação. Até então isso não foi visto como um problema pois o foco estava direcionado no fluxo do tráfego dentro das redes de sensores sem fio. Complicações surgem quando nodos contendo sensores tornam-se parte da Internet conforme a IoT. Neste cenário, a Internet será "traversed " por um grande números de dados gerados por redes de sensores heterogeneas com diferentes características de tráfego. Finalmente, caracterização e modelagem de tráfego é preciso para planejar soluções apropriadas para suportar qualidade de serviço (QoS). Apesar de existirem alguns trabalhos pertinentes para QoS em redes de sensores sem fio, QoS ainda não foi explorado para sistemas de RFID. Um ponto de partida para este estudo é a análise dos mecanismos de QoS utilizados em contextos M2M;

\item \textbf{autenticação}: a autenticação normalmente necessita de uma infraestrutura e servidores apropriados para atingir seus objetivos. Na IoT esta abordagem não é viável visto que as \textit{tags} RFID passivas não podem compartilhar muitas mensagens com os servidores de autenticação. Os nodos devem ser vistos como nodos na Internet, sendo necessário autentica-los mesmo a partir do nodos não pertencentes a rede. Nenhuma solução que foi proposta pela academia ajuda a combater ataques \textit{man-in-the-middle};

\item \textbf{integridade de dados}: soluções para integridade de dados deve garantir que nada consiga modificar os dados em uma transação sem que o sistema consiga detectar estas mudanças. Este problema já foi extensamente estudado em computação tradicional, porém, novos problemas surgem quando sistemas RFID são integrados à Internet, pois permanecem a maior parte do tempo desacompanhados. O dados podem ser modificados por intrusos pouco antes do processo de gravação no nodo, ou ainda enquanto trafegam pela rede. Todas as soluções propostas até então utilizam metodologias criptográficas. Porém, algoritmos criptográficos utilizam uma grande quantidade de recursos em termos de energia e largura de banda, impedindo sua aplicação em ambientes com restrições de recursos como na IoT;

\item \textbf{privacidade}: as formas como os dados poderão ser coletados, minerados e fornecidos na IoT, será completamente diferente da forma que conhecemos hoje, e haverá um número bem grande de ocasiões no qual os os dados pessoais de um usuário poderão ser coletados. Logo, será impossível para os indivíduos controlarem pessoalmente a revelação de seus dados pessoais. Alguns estudos sugerem um \textit{borker} de privacidade, porém, o mesmo não permite que usuários definam políticas de privacidade;

\item \textbf{esquecimento digital}: assim como o custo de armazenamento de informações reduz, a quantidade de dados armazenados aumenta. Portanto, existe a necessidade de criar soluções que periodicamente apagam as informações que não são mais requeridas, reduzindo custos operacionais de buscas na rede;

\end{itemize}

%=======================================================================
\section{Nuvens móveis}
Introdução básica mais uma motivação sobre a necessidade das nuvens móveis.

%sessao para isso??
Comentar sobre proxy remoto contra recursos locais

\subsubsection{Computação na nuvem vs Computação na nuvens móvel}
O que é cloud computing?
O que é mobile cloud computing?
 - Tipos de mobile cloud computing...
 - Colocar desenhos exemplificando os três conceitos.

\subsubsection{Taxonomia da computação na nuvem móvel}
Possiveis problemas nas seguintes áreas:
- Nível operacional 
- Nível usuário final
- Nível de serviços e aplicações
- Nível privacidade, segurança e confiabilidade
- Ciência do contexto
- Gerenciamento de dados

Explicar brevemente cada um deles. Colocar imagem ilustrando todos os conceitos.

Extender para as classificações dos subconceitos, explicando brevemente (1 paragrafo para cada) do que se trata.

Derivar os problemas a serem explorados dentro de cada umas classificações da taxonomia.

%=======================================================================
\section{Bibliotecas de Programação}
Esta seção apresenta algumas bibliotecas de programação que podem ser utilizadas para implementação de sistemas que habilitem a IoT e o compartilhamento de dados entre dispositivos móveis. Ela está organizada de acordo com a tecnologia que fornece funções, iniciando por \textit{middleware} que permitam a criação de sistemas P2P, revisando alguns protocolos de troca de dados entre máquinas M2M, e por fim, analisando brevemente as APIs disponibilizadas pelos maiores fabricantes de \textit{smartphones}.

\subsection{\textit{Middlewares Peer-to-Peer}}
Na literatura é possível encontrar uma série de \textit{middlewares} P2P. Nesta seção dois \textit{middlewares} bem conhecidos no mercado são analisados, o Jabber e o Pastry. A escolha dos mesmo, dá-se pela diferente arquitetura de cada um deles, sendo o primeiro híbrido com um servidor centralizado para troca de identificadores, o segundo totalmente descentralizado.

\subsubsection{Jabber}
O Jabber disponibiliza especificações para desenvolver aplicações com troca de mensagens instantâneas. O Jabber foi inicialmente desenvolvido para aplicações de mensagens instantânes, porém, a infraestrutura disponibiliza por ele pode ser utilizada para o desenvolvimento de aplicações P2P de propósito geral.

\textit{Peers} no Jabber são identificados por um identificador Jabber (JID). Um JID tem a forma \texttt{[nomedopeer@]domínio[/recurso]}. O domínio representa o servidor Jabber para o qual os \textit{peers} se conectam. Ele ainda permite que quaisquer dois \textit{peers} na Internet compartilhem documentos XML contendo mensagens de comunicação (\textit{message documents}), disponibilidade de recursos (\textit{presence documents} ou mensagens de busca/resposta (\textit{Info/Query IQ documents}). A estrutura deste documentos XML é definida pelo Jabber, mas todos os documentos podem ser enxtendidos para incluir informações extras. Os documentos IQ provê um \textit{framework} simples de requisão/resposta para o Jabber, permitindo que \textit{peers} passem buscas e repostas formatadas em XML entre os \textit{peers}.

A arquitetura P2P do Jabber é híbrida, pois ele utiliza um servidor para autenticar os \textit{peers} e resolver os JID para um endereço de rede físico. Entretanto, \textit{peers} podem trocar dados diretamente por meio do estabelecimento de uma conexão que gerenciada por um servidor Jabber \textit{broker}.

\subsubsection{Pastry e Scribe}
Pastry é localizador de objetos descentralizado em conjunto com um sub-sistema de roteamento para aplicações P2P. O Pastry disponibiliza uma API que pode facilmente ser utilizada para elaboração de aplicações P2P.

Cada nodo na rede do Pastry é associado a um identificador de nodo único. Quando apresentado à uma mensagem e um ID, o Patry eficientemente desvia a rota da mensagem para algum \textit{peer} com o ID de nodo numericamente próximo com a chave, dentre os nodos correntes.

O número esperado de passos de desvios é dado por O(log2bN), onde N é o número de \textit{peers} na rede e b é uma constante. A entrega final da mensagem é garantida no Pastry. Ele escolhe um desvio que é dito ser "bom" em relação à metricas de proximidade. Para tanto, ele tem como premissa que cada aplicação implemente uma função que determine a distância para um \textit{peer} Pastry a partir de um dadso endereço IP até o próprio \textit{peer}. Quando um \textit{peer} tem uma lista de endereços para escolher para quem desviar a mensagem, ele sempre escolhe o endereço mais próximo.

O Pastry é auto-organizável. Cada novo nodo que entre em uma rede Pastry envia uma mensagem de união contendo uma chave para a rede através de um nodo de \textit{bootstrap} obtido por meios externos. A mensagem de união é desviada para o nodo numericamente próximo. Todos os nodos no caminho de desvio da mensagem respondem com suas tabelas de estados, no qual estas informações são utilizadas para popular a tabela de estados do novo nodo.

Com Pastry é possível rapidamente e deterministicamente localizar um objeto cujo ID esteja disponível, porém, ele não pode ser utilizado para fazer \textit{multicast} de mensagens no \textit{overlay} P2P para buscar por um objeto de acordo com critérios de seleção.

O Scribe é uma infraestrutura para \textit{multicast} em nível de aplicação construída sobre o Pastry. Ele pode ser utilizado para enviar mensagens, incluindo critérios de busca, para todos os nodos de um grupo Scribe.

\subsection{Comunicação M2M}
Um conceito que vem crescendo principalmente quando de se trata de IoT, é a 
comunicação máquina a máquina (M2M). Este tipo de comunicação é caracterizada pela 
leveza e suavidade dos protocolos, que precisam apresentar um bom desempenho e 
efetividade na troca de mensagens considerando dispositivos com escassez de recursos. 

\subsubsection{MMPI}
O \textit{framework} MMPI (\textit{Mobile Message Passing Interface} é um versão móvel conhecido MPI sobre Bluetooth no qual os dispositivos móveis funcionam como os próprio provedores de recursos. Em vez de utilizar um topologia rede em estrela, como tipicamente são as piconets, o MMPI utiliza uma rede \textit{mesh} totalmente interconectada, no qual cada pode comunicar-se com os outros.

Tarefas como descobrimento de dispositivos e conexões são gerenciadas por bibliotecas disponibilizadas pelo \textit{framework}, eliminando o necessidade de escrever códigos específicos para bluetooth explicitamente. O\textit{framework} é implementado em Java e utiliza uma biblioteca externa chamada BlueCove para controlar as operações Bluetooth. O dispositivo móvel mestre passa os parâmetros da tarefa para os dispositivos escravos que propriamente executam as tarefas.

O sistema MMPI contém três fases durante a inicialização:
\begin{itemize}
\item descobrimento de dispositivos;
\item descobrimento de serviços;
\item formação da rede.
\end{itemize}

O tempo de execução do descoberta de serviços aumenta proporcionalmente a quantidade de dispositivos adicionados na rede. A formação da rede é o  processo de menor tempo na fase de inicialização, com testes mostrando um tempo de 136ms para uma rede com dois nodos e 2,3s para uma rede com quatro nodos.

\subsubsection{XMPP}
XMPP (\textit{Extensible Messaging and Presence Protocol} é um conjunto de tecnologias para mensagens instâneas, presença, multi chat, chamadas de voz e vídeo, colaboração, difusão de conteúdo e desvio generalizados de dados XML.

XMPP foi desenvolvido originalmente pela comunidade do projeto de código aberto Jabber, para disponibilizar uma aberto, seguro, sem \textit{spam} e descentralizado alternativa para serviços de mensagens instâneas disponíveis na época. Ele fornece as seguintes vantagens em comparação com seus concorrentes:
\begin{itemize}
\item aberto: o protocolo XMPP é livre, aberto, público e de fácil entendimento, contendo diversas implementações nas formas de clientes, servidores e componentes de servidores e bibliotecas de código;
\item padronizado: a \textit{Internet Engineering Task Force} (IETF) formalizou os protocolos de núcleo XML como uma tecnologia aprovada de mensagens instantâneas e presença. A especificação XMPP foi publicada como RFC 3920 e RFC 3921 em 2004, e a XMPP \textit{Standards Fundation} continua a publicar novas séries de XEP (continuação e emendas as especificações);
\item descentralizado: a arquitetura de rede XMPP é similar ao email, logo, qualquer pessoa pode rodar seu próprio servidor XMPP. Isto habilita que usuários e organizões tenham total controle sobre a forma como será efetuada suas comunicações;
\item seguro: um servidor XMPP pode ser isolado de uma rede pública, pertencendo a uma intranet por exemplo. A especifição XMPP tem incorporado mecanismo de segurança robustos baseada em SASL e TLS. Os desenvolvedores estão trabalhando para adicionar criptografia fim a fim para elevar ainda mais os padrões de segurança;
\item extensível: o poder do XML permite que novas funcionalidades customizadas sejam adicionadas sobre os protocolos centrais. De forma a manter compatibilidade com versões mais antigas da espeficicação, extensões da mesma são publicadas a parte e não é requeridas sua implementação, permitindo às organizações utilizarem suas próprias extensões privadas;
\item flexível: diversos tipos de aplicações podem ser criados com a utilização do protocolo XMPP, como gerenciamento de rede, ferramentas de colaboração, compartilhamento de arquivos, jogos, sistemas de monitoramento remotos, \textit{web services}, computação nas nuvens, entre outros;
\end{itemize}

O XMPP é utilizado comercialmente em várias aplicações, tendo o Google Talk como uma de suas principais.

\subsubsection{MQTT}
MQTT --- MQ \textit{Telemetry Transport} --- é um protocolo de mensagens
extremamanete simples e minimalista contruído sobre arquitetura \textit{publish/subscribe}. Foi projetado para dispositivos restritivos, com poucos recursos, baixa largura de banda, alta latência de rede e redes não confiáveis. Os princípios do sistem são minimizar a largura de banda de rede e recursos do dispositivo enquanto que tenta garantir confiabilidade e algum grau de garantia na entrega de mensagens. Estes princípios fazem o protocolo ideal para aplicações móveis onde a largura de banda e bateria são escassos, além de habilitar a comunicação máquina a máquina (M2M) no emergente mundo da Internet da coisas (IoT).

O protocolo é baseado no princípio de publicação de mensagens e inscições em tópicos. Mútiplos clientes conectam-se à um \textit{broker}, se inscrevem em tópicos que são se seus interesses, e também publicam mensagens nestes tópicos. O \textit{broker} e o protocolo MQTT atuam com uma interface para todo e qualquer dispositivo se interconectar. Isto significa que, caso existam clientes que escrevam mensagens em serviços específicos, como base de dados, arquivo de textos, ou até mesmo o Twitter, torna-se muito simples adicionar novos sensores ou qualquer outra entrada de dados nestes serviços.

Mensagens no MQTT são publicadas em tópicos. Não é preciso configurar ou criar um tópico, uma simples publicação para um determinado tópico é suficiente para sua criação. Tópicos são tratados de forma hierárquica, usando uma barra "/" como separador. Isto permite que diferentes arranjos sobre informações comuns seja realizado, assemelhando-se a aum sistema de arquivos.

Clientes podem receber mensagens através da criação de inscrições. A inscrição pode ser específica para um tópico, onde somente mensagens para aquele tópico serão recebidas, ou ela pode conter caracteres coringa (\textit{wildcards}), abrangendo uma hierarquia de tópicos.

As funcionalidade de qualidade do serviço (QoS) permitem que o protocolo MQTT disponibilize diferentes qualidades de entrega das mensagens de acordo com o ambiente. O sistema de QoS do MQTT pode ser comparado com o processo de envio de uma carta dos EUA. Uma carta pode ser enviada através do sistema de corrios normal (US \textit{mail}), isto é, sem confirmação de recebimento, ou pode-se optar pelo envio da carta por um provedor de serviços que assegure a entrega \cite{site:ibm}. Existem três opções de QoS:
\begin{itemize}
\item QoS 0 - No máximo uma entrega: com esta opção, as mensagens são entregues de acordo com a eficiencia da camada de rede. Nenhuma resposta
é esperada, e nenhum mecanismo de retransmissão é definido no protocolo.
Este é o nível mais baixo de qualidade de serviço, porém, do ponto de vista de desempenho, é o que agrega mais valor dado sua velocidade para enviar mensagens. Uma mensagem contendo QoS 0 é perdida se o cliente for desconectado inesperadamente ou se o servidor falhar.
\item QoS 1 - Pelo menos uma entrega: neste nível de serviço, o cliente MQTT ou o servidor vai tentar enviar pelo menos uma mensagem, porém pode haver o envio de mensagens dupicadas. Uma resposta é sempre esperada para a mensagem. Caso a resposta não seja recebida, a mensagem é reenviada.
\item QoS 2 - Exatamente uma entrega: este é o nível mais elevado de QoS. Um protocolo adicional, com \textit{handshake} de quatro passos, assegura que mensagens duplicadas não serão entregues para as aplicações. As mensagens são enviadas uma e somente uma vez quando QoS 2 é utilizada.
\end{itemize}

Todas as mensagens podem ser configuradas para retenção. Isto significa que um servidor irá guardar as mensagens após o envio para todos os inscritos. Logo, se um novo membro inscrever-se no tópico cujas mensagens são retidas, as mesmas serão enviadas para este membro. Caso um tópico cujas mensagens não são retidas, seja atualizado esporádicamente, um novo cliente inscrito esperará um longo tempo para receber uma atualização. Com a retenção de mensagens, o cliente receberá as atualizações instantaneamente.

\subsection{APIs para computação móvel}
Os \textit{smartphones} e \texit{tablets} vem ganhando bastante foco nos últimos anos. Dotados de um poder computacional elevado, e diferentes sensores capazes de capturar informações sobre o ambiente, são dispositivos fundamentais na computação moderna. A seguir, é apresentado duas plataformas comerciais de \textit{smartphones}, Android e iOS.

\subsubsection{Android}
Android \textit{Open Handset Alliance} é um sistema operacional de código aberto para dispositivos móveis desenvolvido pelo Google\footnote{https://www.google.com} em conjunto com a \textit{Open Handset Alliance}\footnote{http://www.openhandsetalliance.com/}. Ele foi construído sobre o núcleo do Linux e disponibiliza uma SDK para desenvolvimento de aplicação em Java. 

O Android utiliza a máquina virtual Dalvik para executar seus aplicativos. A Dalvik é otimizada para rodar em dispositivos com restrições de CPU, memória, e alimentação. Ela implementa um subconjunto da plataforma Java 2 SE\footnote{http://www.oracle.com/technetwork/java/javase/overview/index.html}, utilizando bibliotecas da Apache Harmony, tendo vantagens em comparação a outras plataformas móveis que suportam apenas Java 2 ME\footnote{http://www.oracle.com/technetwork/java/javame/index.html}, que carece de funcionalidades. Os arquivos de classes Java devem ser compilados para o \textit{bytecode} Dalvik (formato .dex) e empacotado em um arquivo de aplicação .apk para ser utilizado no Android.

O sistema operacional provê uma interface os dispositivos do sistema e serviços através de um conjunto de pacotes Java, incluindo \texttt{android.os}, \texttt{android.hardware}, \texttt{android.location}, \texttt{android.media}. Este conjunto de funcionalidades torna o acesso e operações em dados multimídia, valores de sensores, dados de uso do sistema, e informações sobre localização. Diferentemente de outros sistemas operacionais, aplicações android podem utilizar o sistema de arquivos diretamente, sendo possível manipular arquivos de mesma forma tradicional que qualquer sistema Unix. O Android também disponibiliza uma interface de acesso ao \textit{shell}, porém carece de várias funcionalidades de um típico Linux \textit{shell}.

\subsubsection{iOS}
O iOS é um sistema operacional desenvolvido pela Apple\footnote{http://www.apple.com/} para dispositivos móveis. O primeiro SDK para desenvolvimento foi liberado em 2008 para habilitar o desenvolvimento de aplicações nativas para iOS. A SDK permite o desenvolvimento de aplicações para os dispositivos móveis da Apple, como iPhone, iPod e iPad, bem como testar as aplicações em um simulador. Porém, só é possível transferir uma aplicação para um dispositivo físico depois do pagamento de uma taxa e inscrição no programa de desenvolvedores da Apple (iOS \textit{Developer Program Fee}). A partir da versão 3.1 do Xcode, ele é ambiente de desenvolvimento para dispositivos iOS, e assim como aplicações para Mac OS X, aplicações para iOS são escritas em Objective-C com compatibilidade para C e C++. 

O iOS utiliza uma variação do núcleo XNU também utilizado no sistema operacional Mac OS X, portanto as ferramentas utilizadas para desenvolver no iOS também são baseada no Xcode. A API do iOS é divida nos seguintes conjuntos:
\begin{itemize}
\item \textit{Cocoa Touch}: controla enventos multi-toque, controles físicos de acesso, suporta ao acelerômetro, ferramentas para localização da aplicação e suporte à câmera.
\item \textit{Media}: OpenAL, gravação e mixagem de áudio, reprodução de vídeos, formatos de arquivos de imagens, modelos gráficos Quartz, OpenGL ES e \textit{Core Animation}.
\item \textit{Core Services}: protocolos de rede, base de dados SQLite, \textit{Core Location}, \textit{Threads}, \textit{Core Motion}.
\item \textit{Mac OS X Kernel}: suporte a TCP/IP, \textit{sockets}, gerenciamento de energia, sistema de arquivos e segurança.
\end{itemize}

%=======================================================================
% Trabalhos Relacionados
%=======================================================================
\chapter{Trabalhos Relacionados}
%TODO

\section{\textit{Middlewares} RFID}
A seguinte seção mostra brevemente alguns \textit{middlewares} encontrados na literatura em conjunto com suas caractrísticas principais. Para diferenciação das tecnologias, a seção está divida em \textit{middlewares} que seguem a especificação da EPCglobal, e \textit{middlewares} implementados com base na especificação do NFC Forum. Finalizando está uma análise comparativa das tecnologias utilizadas para construção dos \textit{middlewares} citados.

\subsection{\textit{Middlewares} EPCglobal}
Os \textit{middlewares} citados nas subseções seguintes todos são baseados nas especificações da EPCglobal. Os \textit{middlewares} escolhidos possuem diferentes características arquiteturais e abordagens de implementação das mesmas especificações. 

\subsubsection{Fosstrak}
Fosstrak é uma implementação de código aberto baseada na especificação de RFID da EPCglobal proposto em \citetexto{fosstrak}, após uma pesquisa extensiva realizada pela ETH Zurich. Ele possui três módulos principais: módulo de leitura, \textit{middleware} de filtragem e agregação, e um serviço de informações (EPCIS) para o contexto de aplicação \textit{jaroodi:09}.

O módulo de leitura é responsável pelo gerenciamento dos dados, que compreende, a disseminação síncrona ou assícrona dos dados e filtragem e agregação em nível de leitor. Ele pode ser utilizado em três módulos primários de operação:
\begin{itemize}
\item o primeiro modo encapsula um protocolo de leitura de RFID proprietário que é executado a partir de um servidor diferenciado;
\item o segundo modo utiliza leitores Fosstrak em modo de simulação que farão uso de leitores RFID embutidos pertecentes a diferentes fabricantes, o que se torna muito útil caso nenhum leitor físico esteja disponível;
\item o terceiro modo utiliza uma implementação de leitores Fosstrack diretamente nos leitores RFID para possibilitar funcionalidades de filtragem dos dados e capacidade de dissiminação. 
\end{itemize}

Após a captura dos dados relevantes das \textit{tags} o sistema notifica o \textit{middleware} de filtragem e agregação que combina dados de vários leitores diferentes. Este conjunto de dados compõem um \textit{EPC report} que é enviado para as aplicação inscritas de acordo com regras de escalonamento. O \textit{middleware} de filtragem e agregação desacopla os leitores da aplicação, criando uma forma de incorporar funcionalidades adicionais para tratamento dos dados gerados por RFID \citetexto{ahmed:10}.

A interface entre o \textit{middleware} de filtragem e agragação e a aplicação em questão é baseado na especificação ALE da EPCglobal. Por também possuir funcionalidades de agregação de dados, ele pode omitir eventos de leitura redundantes provenientes de diferentes leitores em um mesmo local. O EPCIS é o componente responsável por receber os dados RFID do \textit{middleware} de filtragem e agragação e traduzir os dados para eventos diponibilizando-os para a aplicação. A implementação do EPCIS compreende três módulos: repositório EPCIS, módulo de captura EPCIS, responsável por receber os dados RFID, e o módulo de pesquisa EPCIS, cujo principal funcionalidade é a habilitar a leitura de eventos do repositório.

O Fosstrak provê uma solução geral para tratar grandes quantidades de dados utilizando uma abordagem modular para a execução de diferentes atividades. Porém, atualmente ele não fornece persistência para os dados RFID no \textit{middleware} de filtragem e agragação e possui suporte a protocolos de leitura proprietários limitado \cite{jaroodi:09}.

\subsubsection{WinRFID}
WinRFID é um \textit{middleware} RFID projetado e desenvolvido pela Universidade da California dos Estados Unidos \cite{prabhu:08}. Sua arquitetura é baseado em cinco camadas: camada de \textit{hardware} RFID, camada de protocolo, camada de processamento de dados, camada de \textit{framework} XML e camada de apresentação de dados.

A camada de \textit{hardware} RFID trata da execução, configuração e problemas derivados da comunicação com leitores, \textit{tags} e com os módulos de entrada/saída de seus leitores. Existem três componentes principais nesta camada: leitores, \textit{tags} e entrada/saída. A camada de protocolo abstrai os protocolos de leituras de \textit{tags} mais comuns, como, ISO 15693, ICode, EPC \textit{Class} 0 e EPC \textit{Class} 1. Esta camada, executa um motor de protocolos que é responsável por interpretar e processar os dados obtidos das \textit{tags} em formato de dados bruto compatível com os protocolos citados acima. A camada de processamento de dados implementa regras para processar os dados brutos vindos da camada de protocolo de forma a remover as leituras duplicadas. Qualquer anormalidade nesta camada é tratada por diferentes formas de alarmes, como emails, mensagens ou ações definidas pelo usuário. Então, os dados limpos e formatados são direcionados para a camada de \textit{framework} XML que aplica o padrão XML sobre os dados tornando-os apresentáveis para diferentes aplicações. A camada de apresentação dos dados utiliza os dados fornecidos pelo \textit{framework} XML para visualização e tomada de decisão.

O WinRFID foi projetado com a tecnologia .NET \textit{framework} que facilita a adição de funcionalidade para as aplicações através de \textit{plugins} em tempo de execução. Desta forma, WinRFID tem um motor de regras adaptáveis, logo usuários podem facilmente adicionar suas próprias regras.

\subsubsection{RF\textsuperscript{2}ID}
O RF\textsuperscript{2}ID (\textit{Reliable Framework for Radio Frequency Identification} apresentado em \citetexto{ahmed:07} foi projetado e implementado com o propósito de ser um \textit{middleware} com características de qualidade como confiabilidade, balanceamento de carga, alto \textit{throughput}, escalabilidade e organização do dados. A arquitetura do \textit{middleware} é baseda em dois conceitos abstratos: leitores virtuais (VR) e caminhos virtuais (VP). 

Os VRs são abstrações criadas para tratar a tendência a erros inerente dos leitores físicos e antenas de forma escalável \cite{ahmed:10}. Os VRs são os elementos de computação distribuída do sistema. Cada VR está associado com um conjunto de leitores RFID físicos dentro de uma região geográfica. As responsabilidades de cada VR incluem filtragem dos dados provenientes dos leitores físicos conectados e de outros VRs, adição de estampa de tempo aos dados, gerenciamento do caminho virtual e gerenciamento de consultas. 

Os caminhos virtuais são canais lógicos dinamicamente criados para capturar o fluxo de informações entre os VRs a medida em que os objetos com \textit{tags} RFID movimentam-se no ambiente. Usando este conceito de caminhos em nível de sistema traz vantagens na implementação de algumas funcionalidades. A carga do sistema pode ser distribuida entre os vários leitores que consituem um VP específico.  Diferentes atributos de QoS podem ser definidos para um caminho, como precisão e níveis de prioridade utilizados pelos VRs para operar sobre os dados em um caminho correspondente. Em adição, torna-se trivial o suporte para operações relacionadas com o fluxo de dados, como busca por resultados de pesquisas e projeções futuras do comportamento do sistema com base no histórico, uma vez que existe uma representação interna dos dados baseada em atributos do caminho \cite{ahmed:10}.

O RF\textsuperscript{2}ID habilita uma forma escalável de comunicação entre regiões geográficas tendo como abordagem o fluxo de dados entre caminhos para gerenciar os dados RFID gerados.

\subsubsection{MARM: \textit{Middleware} RFID multi agentes}
O MARM foi projetado utilizando o conceito de engenharia de software orientado à agentes (AOSE) que é um paradigma de engenharia software emergente que vem ganhando espaço nas mais variadas aplicações. A motivação principal para construção do MARM, era projetar um \textit{middleware} para o processamento e gerenciamento de dados produzidos por sistemas RFID para uma aplicação de gestão de ativos utilizada pela Universidade Central de Tecnologia (CUT) da África do Sul. 

O MARM utiliza SMURF \cite{smurf} para silenciar os dados não confiáveis capturados pelos leitores RFID e um modelo temporal para facilitar o processamento de eventos de aplicação. A arquitetura do MARM foi implementada utilizando a metodologia PASSI \cite{passi}, que é uma das metodologias AOSE para o projeto e desenvolvimento de sistemas multi agentes (MAS). A arquitetura é divida principalmente em três camadas: gerenciamento de dispositivos, gerenciamento de dados e interface. As aplicações, na camada de interface, especificam os dados que desejam receber e os tipos de dados que querem que seja relatados para os agentes de gerenciamento de dados. Esses tipos de dados incluem gerenciadores de \textit{ECReport-Request} e \textit{ECReportSpec}. Agentes gerenciadores de dados por sua vez, comunicam-se com os agentes leitores da camada de dispositivos, colecionam os dados brutos, processam esses dados, geram as requisições e por fim enviam os dados processados para a aplicação. 

Dois diagrama de classes de ontologias foram modelados para alcançar o objetivo da coordenação entre agentes com sucesso em tempo aceitável. Um deles é o \textit{Domain Ontology Description} (DOD) que descreve as ontologias de projeto do \textit{middleware} através da representação de predicados do domínio e alguns ações dos agentes. O outro diagrama é o \textit{Communication Ontology Description} (COD) que descreve as ontologias sobre o conhecimento dos agentes e suas associações.

O MARM foi projetado para o processamento de eventos de aplicação dentro do próprio \textit{middleware}, além de prover funcionalidades semelhantes aos demais \textit{middleware} como captura de dados, tratamento de erros e processamento de eventos.

\subsubsection{REFiLL}
REFiLL é um \textit{middleware} leve para filtragem e agregação de dados baseado na arquitetura de rede da EPCglobal \cite{anagnostopoulos:09}. Foi projetado como um ambiente de programação, que provê flexibilidade para o desenvolvedor de aplicações RFID na presença de plataformas de \textit{hardware} heterogeneas. 

O REFiLL está posicionado entre a camada de virtualização de leitores e a camada ALE. Seu motor de operação compreende filtros e gerenciadores de saída, no qual cada filtro tem os seguintes atributos: portas de entrada, portas de saída e processadores de eventos. Os filtros são definidos e inconectados com a ajuda de arquivos XML editáveis que são compilados para código Java de forma a permitir funcionalidades de agregação e filtragem dos eventos RFID.

O gerenciador de saída habilita a funcionalidades de recebimento dos dados processados dos filtros e abstrações para sistemas de saída como RDBMS, arquivos, \textit{sockets} e \textit{web services}.

\subsubsection{\textit{Hybrid Middleware}}
O \textit{Hybrid middleware} é um sistema baseado em rede de comunicação P2P proposto por \citetexto{cervantes:07}. Ele desenvolvido exclusivamente para um sitema de gerenciamento de estacionamento eletrônico de um campus de universidade. 

A arquitetura do \textit{Hybrid middleware} consistem em grupos de sobreposição (\textit{overlay}) de \textit{peer nodes}, como o gerenciadore de grupo de membros, o coordenador de grupo de comunicação, o gerenciadorde eventos do estacionamento e os conectores de serviços. O gerenciamento de membros que inclui a criação, destruição e alteração dos membros do grupo é tratado pelo nodo de gerenciamento de grupode membros. O nodo coordenador de comunicação em grupo assegura a efetividade e tempo de operação entre os nodos membros, de forma que qualquer mudança no estado do sistema de estacionamento seja detectado com atraso mínimo. O trabalho do nodo gerenciador de eventos do estacionamento é enviar todos os eventos para o serviço de armazenamento de dados, enquanto os conectores de serviço executam o controle de nodos individuais.

O \textit{Hybrid middleware} foi projetado para atender dois tipos de eventos de estacionamento: "entrada" e "saída" que acontecem repectivamente quando um veículo entra em determinada vaga do estacionamento e quando deixa sua vaga.

\subsection{\textit{Middlewares} NFC}
O \textit{middleware} apresentado na subseção seguinte foi construído com base na especificação da NFC Forum. Além disso ele tem sua arquitetura voltada para execução em dispositivos móveis que contenham tecnologias de \textit{hardware} compatíveis com NFC.

\subsubsection{MORENA}
O MORENA \cite{carreton:12} é um \textit{middleware} para programação de aplicações Android baseado no conceito de orientação a objetos distribuída que trata cada objeto com capacidades de comunicação NFC constituído com \textit{tags} RFID como objetos remotos intermitentes. Ele foi projetado sobre a API do Google Android NFC, que atualmente é a API mais avançada para o processamento de NFC para dispositivos móveis disponível no mercado.

A representação dos objetos como referências remotas de primeira ordem, que permite somente comunicação assíncrona com a \textit{tag} que ele refere-se, foi inspirada no paradigma de programação orientada à ambientes. Isso permite que o programador implemente aplicações móveis que leiam ou gravem em RFID \textit{tags} sem precisar controlar toda e qualquer falha durante esse processo manualmente e sem bloquear a aplicação com operações de leitura e escrita.

Com no base na programação orientada à ambientes, os seguintes conceitos foram implementados no \textit{middleware}: rastreamento de conectividade, comunicação assíncrona, desacoplamento de tempo e referências de primeira ordem para objetos remotos. O conceito de rastreamento de conectividade em sistema de RFID é utilizado para rastrear quando as \textit{tags} que entram e saem do escopo de cobertura do leitor, notificando estas mudanças na conectividade. Como a comunicação com as \textit{tags} RFID é intermitente e desconexões podem ocorrer a qualquer instante, a comunicação assíncrona é utilizada para não bloquear a aplicação enquanto a \textit{tag} está fora do alcance de comunicação. O caráter de comunicação intermitente tende a gerar diversas falhas durante o processo de leitura ou escrita, tendo que executar diversas tentativas até alguma ser bem sucedida. O desacoplamento de tempo assegura que a aplicação não irá bloquear ou relatar falhas no processo de leitura ou escrita das \textit{tags} sem executar várias tentativas. Por último, as referências de primeira ordem para objetos remotos são utilizadas para representar uma \textit{tag} RFID como um objeto remoto, permitindo encapsular fluxos de controle que habilitam o programador de registrar funções observadores para ser notificado caso determinada ação aconteça.

O MORENA oferece duas camadas de abstração. No nível mais alto, estão os objetos Java especiais chamados \textit{things} que casualmente podem estar conectados a uma \textit{tag} RFID específica, no qual podem converter automaticamente os dados lidos ou gravados para o formato correto. No nível mais baixo, está a interação, através de uma referência, com uma simples \textit{tag} RFID, que permite a operações de leitura e escrita assíncronas com estratégias de conversão de dados customizadas.

Os \textit{middlewares} baseado nas especificações da EPCglobal não são destinados para aplicações móveis, por exemplo, executadas em \textit{smartphones}. Porém mesmo assim é possível encontrar na literatura aplicações móveis que façam uso de RFID, como em \citetexto{siden:11} onde uma aplicação para cuidados em domicílio é proposta, ou em \citetexto{watfa:11} que mostra uma aplicação para restreamento de objetos pessoais. Em contraste, o MORENA não é destinado para aplicações industriais que necessitam lidar com uma quantidade massiva de \textit{tags} RFID, e portanto, requerem maior escalabilidade.

\subsection{Análise comparativa dos \textit{middlewares RFID}}
A maioria dos \textit{middlewares} discutidos na seção anterior são fortemente ligados a ideia de encontrar formas para tratar o processamento e gerenciamento dos dados brutos provenientes dos leitores RFID eficientemente. Uma análise sobre a modo de operação de cada \textit{middleware} revela que esta eficiência na foma de gerenciamento dos dados de RFID pode ser alcançada com os seguintes passos:
\begin{itemize}
\item remoção de leituras duplicadas;
\item agregação do dados provenientes de diferentes leitores;
\item disseminação dos dados eficiente.
\end{itemize}

Um \textit{middleware} RFID geralmente precisa tratar uma grande quantidade de dados recebidos de muitos leitores RFID diferentes para posteriormente compartilhar-los com as aplicações. Para tanto, é necessário que cada \textit{middleware} contenha um sistema confiável que assegure um fluxo ininterrupto de dados RFID corretos e pertinentes às aplicações. Através do emprego de diferentes técnicas de gerenciamento de eventos cada um dos \textit{middlewares} citados consegue garantir a operação do sistema. 

Seguindo os critérios de comparação utilizados por \citetexto{jaroodi:09}, a Tabela~\ref{tab:compmidrfid} mostra uma comparação dos \textit{middleware} em relação a mecanismos de confiabilidade, escalabilidade, balanceamento de carga, gerenciamento de dados e segurança. É importante destacar que o MORENA está nesta tabela a título de curiosidade, pois o propósito do \textit{middleware} é a utilização em dispositivos móveis e aplicações não industriais, diferentemente das outras soluções.

Com a aderência do NFC por parte dos fabricantes de \textit{smartphones}, a tendência é que novos sistemas semelhantes ao MORENA sejam propostos, sendo possível assim uma comparação justa entre os sistemas.

\begin{table}
	\caption{Comparação dos \textit{middlewares} RFID}
	\label{tab:compmidrfid}
	\centering%
	\begin{minipage}{\textwidth}
		\footnotesize
		\resizebox{\textwidth}{!} {
		\begin{tabular}{|l|l|l|l|l|l|}
			\hline
%           Header Line 1			
			\textbf{\textit{Middleware}} & \textbf{Confiabilidade} &
			\textbf{Escalabilidade} & \textbf{Balanceamento} &
			\textbf{Gerenciamento} & \textbf{Segurança}         \\
%           Header Line 2
			\textbf{RFID} & & & \textbf{de carga} & \textbf{de dados} &  \\
			\hline
%           Line 1			
			Fosstrak & Implementação & Implementação do   & Subscrição  & Especificação & Mecanismo de    \\   
			         & do protocolo  & leitor em três     & de leitores & ALE da        & subscrição      \\
			         & de leitura    & modos: servidor    &             & EPCglobal     & retroalimentado \\
			         & EPC           & diferenciado,      &             &               &                 \\
			         &               & modo de simulação, &             &               &                 \\
			         &               & leitores RFID      &             &               &                 \\
			\hline
%           Line 2						
			WinRFID & Regras de     & Módulos      & Não     & Persistência de & Autenticação \\
					& processamento & distribuídos & Tratado & dados e motor   & a restrição  \\
					&               &              &         & de regras de    & de acesso    \\
					&               &              &         & negócio         &              \\  
			\hline
%           Line 3						
			RF2ID & Leitores & Caminhos virtuais & Gerenciamento & Servidor de & Não     \\
			      & virtuais & entre leitores    & de caminhos   & nomes e     & Tratado \\
			      &          & virtuais e        &               & servidor de &         \\
			      &          & físicos           &               & caminhos    &         \\
			\hline
%           Line 4								         
			MARM & SMURF & Sistema Multi & Não     & Modelo de  & Não     \\
		         &       & Agentes       & Tratado & dados      & Tratado \\
		         &       &               &         & temporal   &         \\				        
		         &       &               &         & para os    &         \\
		         &       &               &         & dados RFID &         \\
			\hline
%           Line 5 
			REFiLL & Motor REFill  & \textit{Framework} leve & Não     & Filtros & Não     \\
			       & com           & para programação        & Tratado & REFiLL  & Tratado \\
			       & implementação & do \textit{middleware}  &         &         &         \\
			       & de EPC-RC     &                         &         &         &         \\
			\hline			
%           Line 6 			
			\textit{Hybrid}     & Modelo de    & Rede multi anel & Sistema P2P & Infraestrutura  & Não     \\
			\textit{Middleware} & comunicação  & P2P             &             & de notificação  & Tratado \\
			                    & em grupo P2P &                 &             & de eventos      &         \\
			                    &              &                 &             & descentralizada &         \\
			\hline
%           Line 7
			MORENA & Abstrações   & Não     & Objetos      & Classes \textit{Thing} & Não     \\
			       & baseadas no  & Tratado & distribuídos &                        & Tratado \\
			       & paradigma de &         & remotos      &                        &         \\
			       & programação  &         &              &                        &         \\
			       & orientada à  &         &              &                        &         \\
			       & ambientes    &         &              &                        &         \\
			\hline			
		\end{tabular}
		}
		\fonte{Adaptado de \citetexto{jaroodi:09}}
	\end{minipage}
\end{table}

\section{Implementações de Nuvens móveis}
Existem várias implementações de nuvens móveis já propostas na literatura. Esta seção visa apresentar algumas implementações, suas característias principais e uma visão geral da arquitetura de cada uma. Finalizando o capítulo, encontra-se uma análise comparativa entre as soluções apresentadas identificando algumas lacunas em suas construções.

\subsection{Spectra}
Spectra \cite{flinn:02} é um sistema remoto de execução para clientes alimentados por bateria utilizados em computação pervasiva. O Spectra permite que aplicações combinem a mobilidade de pequenos dispositivos com o grande poder computacional de servidores estáticos. O Spectra é alto ajustável, ele monitora tanto a utilização de recursos da aplicação como a disponibilidade de recursos no ambiente, determinando dinamicamente como e onde executar os componentes da aplicação. Logo, com esta propriedade alto ajustável, o Spectra promove o equilíbrio entre objetivos concorrentes: desempenho, conservação de energia e qualidade da aplicação.

A estratégia de \textit{offloading} utilizada é baseada em servidores pré-instalados acessíveis por meio de RPC. As aplicações utilizam RPC para invocar funcionalidades em servidores locais ou remotos. Quando um dispositivo precisa descarregar uma aplicação para um servidor, o cliente consulta uma base de dados que armazena informações sobre os servidores, como a disponibilidade corrente, carga da CPU e etc \cite{fernando:13}.

Os servidores possuem códigos da aplicação pré-instalados atuando como serviços. Os desenvolvedores necessitam particionar manualmente a aplicação, especificando quais métodos são candidatos para serem descarregados para o servidor. O \textit{framework} decide em tempo de execução de acordo com a carga dos recursos já mencionados, se alguma parte será descarregada e para qual servidor hospedeiro ela irá.

O Spectra foi um dos primeiros sistemas a implementar o conceito de \textit{cyber-foraging} para dispositivos móveis que apresenta métodos para balancear o custo contra os benefícios da descarga de partes do código para os servidores hospedeiros.

\subsection{Hyrax}
O Hyrax \cite{marinelli:09} é uma plataforma derivado do Hadoop\footnote{http://hadoop.apache.org/} que suporta computação nas nuvens em \textit{smartphones} com sistema operacional Android. Apache Hadoop é uma implementação de código aberto de \textit{MapReduce} que provê uma interface virtualizada para um aglomerado de computadores arbitrariamente escalado.

O Hyrax permite que aplicações utilizem dados e executem tarefas computacionais de forma convenientemente em redes de dispositivos móveis heterogeneos e servidores. Através da gerência do número de dispositivos e tolerando a saída de nodos, a plataforma habilita que aplicações utilizem recursos distribuídos abstratamente, característica natural de uma nuvem computacional.

Em sua arquitetura, um servidor central com acesso à cada dispositivo móvel coordena os dados e tarefas. Os \textit{smartphones} comunicam-se entre si através de uma rede 802.11g isolada. Como em uma implementação de Hadoop, o Hyrax também possui instancias de um \textit{NameNode} e um \textit{JobTracker} rodando no servidor central com acesso aos dispositivos. Este servidor não processa nenhuma das tarefas, ele é responsável somente por coordenar os dados e tarefas. Cada dispositivo móvel possui instancias de um \textit{DataNode} e um \textit{TaskTracker} rodando em serviços diferenciados, além de \textit{threads} de controle para acesso e gravação de dados no sistema de arquivos distribuído do Hadoop (HDFS). 

Os processos \textit{TaskTracker} e \textit{DataNode} de cada dispositivo periodicamente comunicam-se com os processos \textit{JobTracker} e \textit{NameNode} do servidor central. Esta comunicação, que possui a forma de pulso, é utilizada para sinalizar que a os dispositivos móveis ainda estão conectados e que o \textit{JobTracker} pode enviar tarefas em resposta aos pulsos.

O Hyrax explora a possibilidade de utilizar aglomerados de dispositivos móveis como provedores de recursos mostrando a viabilidade de construção deste tipo de nuvem móvel.

\subsection{MobiCloud}
MobiCloud \cite{huang:10} é um \textit{framework} para nuvens móveis, que em adição aos seriviços tradicionais de computação, também oferece suporte para redes \textit{ad hoc} móveis (MANETs), considerando os dispositivos móveis como nodos de serviço. Para habitar este serviço, o \textit{framework} tem como objetivo endereçar problemas como: gerenciamento de confiança, roteamento seguro e gerenciamento de riscos. 

Uma MANETs tradicionais podem ser transformadas em uma arquitetura orientada a serviços com MobiCloud. Cada nodo móvel pode operar como um provedor de serviços ou como um serviço de \textit{broker}, dependendo de suas capacidades computacionais, infraestrura de comunicação e disponibilidade de recursos.

Todo nodo de serviço é incorporado à nuvem como um componente virtualizado que por sua vez é espelhado, criando um cópia adicional também na nuvem. Esta cópia espelhada, conhecida como \textit{Extended Semi-Shadow Images} (ESSIs) não são exatamente as imagesn virtuais dos serviços, pois um ESSI pode ser um clone perfeito, um clone parcial, ou apenas uma imagem que extende algumas funcionalidades do dispositivo físico.

Uma camada de roteamento e comunicação virtualizada para a MANET é estabelecida pelos ESSIs para auxiliar os nodos móveis físicos que eles representam. Como um dos principais objetivos do MobiCloud é fornecer uma arquitetura de serviços segura, um serviço chamado \textit{Virtual Trusted and Provisioning Domain} (VTaPDs) foi estabelecido com o intuito de tratar fluxos de informações em vários domínios de segurança.

O serviço VTaPD identifica fluxos e cria domínios virtuais, que através destes, um usuário pode seguramente executar múltiplas aplicações em diferentes domínios de segurança, além de separar serviços de acordo com configurações baseados em contexto. As informações de contexto das MANETs
são gravados pelo gerenciador VTaPD e utilizadas pelo gerenciador de risco e procedimentos de detecção de intrusos. Exemplos de informações contextuais são apresentadas: valores de sensores do dispositivo, localização e estado dos dispositivos vizinhos. Valores de parâmetros relacionados à dispositivos, redes, conteúdo e segurança, como níveis de bateria, conectividade e privacidade são utilizados para prover migrações de serviços cientes do contexto. A partir deste processamento e agrupamento de dados centralizados, o conhecimento sobre todo o sistema da MANET é adquirido, tornando possível a identificação de nodos maliciosos.

O MobiCloud descreve um sistema no qual dispositivos móveis utilizam componentes da aplicação chamados \textit{weblets} que podem tanto ser migrados para a nuvem, como executados localmente no dispositivo móvel. A alocação de recursos é baseada um modelo de processo de decisão Semi-Markov (SMDP). O modelo SMDP é baseado em três estados dentro da nuvem: requisição de novo \textit{weblet} ou requisição interdomínio, requisição de transferência de \textit{weblets} intra-domínio, e domínio de partida de \textit{weblets}.

Quando a nuvem recebe uma requisição de migração de um dispositivo móvel, ela somente aceitará a requisição caso exista um ganho global do sistema. O ganho global do sistema é baseado na maximização dos benefícios da nuvem e redução das despesas do usuário móvel. As despesas do usuário móvel dependem de dois fatores principais: consumo de energia do dispositivo móvel e custos monetários para descarga de código para a nuvem. O ganho global do sistema ainda considera o custo de CPU na nuvem de acordo com a ocupaçao da imgem virtual. A modelo de recompensa é utilizado para calcular os despesas baseados no estado do sistema e na ação correspondente \cite{fernando:13}.

\subsection{Cuckoo}
Cuckoo \cite{kemp:12} é um \textit{framework} que simplifica o desenvolvimento de aplicações para \textit{smartphones} que beneficiam-se da descarga de computação e proporciona um sistema dinâmico que em tempo de execução, decide se parte de uma aplicação será executada localmente ou remotamente. O \textit{framework} foi desenvolvido utilizando Java, com modelos de \textit{proxy/stub}, portanto é interoperável com o sistema Android. 

O Cuckoo pode descarregar para qualquer recurso que rode uma máquina virtua Java (JVM), seja ele comercial, como o EC210 da Amazon, ou privado, como mini núvens compostas por \textit{laptops} ou aglomerados locais. Porém, outros dispositivos móveis não são mencionados como potenciais provedores de recursos \cite{fernando:13}. 

Os objetivos centrais do \textit{framework} de descarga são aumentar o desempenho geral do sistema e reduzir a utilização de bateria. Como mecanismo de comunicação, foi escolhido o Ibis \textit{High Performance Programming System} que provê interfaces que abstraem a rede sem fios utilizada, sendo ela WiFi, Bluetooth ou redes móveis utilizadas para telefonia.

Para utilizar o Cuckoo, aplicações precisam ser re-escritas de forma que suportem a execução remota bem como execução local. Com este propósito, o modelo de programação, operando como uma interface do sistema, utiliza o modelo de atividade/serviço já existente no Android para separar os serviços e atividades. Como serviços são compreendidos métodos de computação intensiva que sejam candidatos para descarga, e atividades são métodos interativos da aplicação.

Um objeto \textit{proxy} é criado em cada atividade ligada com a implementação local. Em adição à implementação local, o Cuckoo gera um código para a mesma implementação no lado do serviço remoto que pode, ou não, ser identica à local. Tais diferenças podem considerar implementações remotas específicas para arquiteturas multi núcleos que tiram proveito máximo de paralelismo. Na ausência de recursos remotos, por exemplo a falta de conectividade, a aplicação pode rodar inteiramente com recursos locais do próprio \textit{smartphone}.

Entretando, os autores não apresentam uma solução para decidir quando fazer a descarga da aplicação. Esta funcionalidade foi incluída como passo de pesquisa futuro, e atualmente o \textit{framework} sempre faz a descarga de partes da aplicação se o dispositivo possui conectividade com uma nuvem de recursos.

\subsection{Cloudlets}
Uma Cloudlet \cite{satyanarayanan:09} é similar a um pequeno \textit{data center} que está situado em áreas e lugares predeterminados que estão conectados à uma grande nuvem via Internet. Segundo \citetexto{satyanarayanan:09}, internamente, uma cloudlet assemelha-se com um aglomerado de computadores multi núcleos, com conectividade interna gigabit e WLAN de alta largura de banda. Assim, os dispositivos móveis estão fisicamente próximos dos recursos que compõem a cloudlet e funcionam como clientes finos enquanto a computação intensiva acontece do dentro da cloudlet. 

Os dispositivos móveis devem estarem conectados à cloudlet através de uma conexão sem fios de baixa latência e alta largura de banda para garantir respostas interativas em tempo real. Se o usuário mover-se para uma região fora do alcance da cloudlet, o dispositivo móvel pode recorrer a um modo de serviço degradado que conecta à nuvens distantes ou até mesmo operar localmente. 

As cloudlets devem ser descentralizadas, dispersas e auto gerenciáveis, com conectividade à internet e controle para inicialização. Eles podem pertencer a qualquer negócio local como cafeterias, escritórios e restaurantes, de contra partida às nuvens que pertencem à grande organizações como Google e Amazon. A cloudlet portaria apenas \textit{cache} de informações também disponibilizadas em outros lugars, de forma a perda de uma cloudlet não se tornaria desastrosa para o sistema em geral. 

A solução utilizada para implementação da cloudlet é a customização transiente da infraestrutura da cloudlet utilizando tecnologias de \textit{hardware} virtuais (VM). A natureza transiente significa que customizações pre-uso e limpezas pós-uso podem restaurar a infraestrutura da cloudlet para seu estado original após cada uso. A VM enscapsularia e separaria a aplicação convidada do \textit{software} do servidor da cloulet. Esta abordagem baseada em VMs é mais estável do que outras alternativas como migração de processos, e é mais flexível do que virtualização baseada em linguagens.

\citetexto{satyanarayanan:09} considerou ainda duas abordagens para transferir o estado da VM de um dispositivo móvel para a cloudlet: migração de VMs e síntese dinâmica de VMs. Destas duas, existe o destaque para a síntese dinâmica pois seu desempenho depende exclusivamente dos recursos locais e falhas de rede não afetam a síntese das VMs.

\subsection{CloneCloud}
CloneCloud \cite{chun:11} é um sistema que transforma aplicações móveis automaticamente para tirar vantagem da nuvem. O sistema consiste em um particionador de aplicações flexível e um executador de tarefas. Sua principal função é permitir que uma aplicação móvel sem quaisquer alterações, rodando sobre uma VM em nível de aplicação, possa descarregar parte de sua execução para cópias do dispositivo operando na nuvem.

O CloneCloud é mais um sistema que utiliza migração de VM como forma de descarga de parte da aplicação para um servidor rico em recursos através de 3G ou WiFi. Ele utiliza uma combinação de análise estática e perfils dinâmicos para particionar as aplicações automaticamente à uma granularidade fina, enquanto otimiza o tempo de execução e consumo do dispositivo para um determinado recurso computacional e ambiente de comunicação. Em tempo de execução, o particionamento de uma aplicação é efetivado através de três ações:
\begin{itemize}
\item migração de uma \textit{thread} de um dispositivo móvel para um clone na nuvem;
\item execução da partição na nuvem;
\item reintegração da \textit{thread} migrada de volta ao dispositivo móvel.
\end{itemize}

É empregado um modelo de custo que analisa o custo envolvido na migração e execução na nuvem e compara contra o custo da execução monolítica. O sistema utiliza um \textit{Dynamic Profiler} para agrupar os dados utilizados na análise de benefícios, que é posteriormente utilizado para alimentar o \textit{Optimization Solver} que decide qual método precisa ser migrado, de forma que o custo para a migração e execução será minimizado. Como custo, o autor refere-se para tempo de execução, eneria consumida e disponibilidade de recursos.

Porém, o CloneCloud assume que o ambiente para clonar VM é por natureza confiável, e mencionam que o estabelecimento de confiabilidade e segurança são trabalhos futuros.

\subsection{Scavenger}
O Scavenger \cite{kristensen:10} é um sistema que utiliza \textit{cyber foraging} para suportar o desenvolvimento de aplicações móveis, que utiliza o uso móvel de recursos computacionais através do uso de ambiente de execução de código móvel customizado e um novo escalonador adaptativo de perfil duplo.

O \textit{framework} permite que dispositivos móveis descarreguem partes da aplicação para um ou mais servidores hospedeiros. Segundo testes realizados, é mais eficiente em termos de desempenho, executar a aplicação em múltiplos servidores hospedeiros em paralelo.

O escalonador é utilizado para a avaliação de custos. O método de avaliação de custos é baseado na velocidade dos servidores hospedeiros, medida por testes de \textit{benchmarking}. O componente do escalonador considera os seguintes fatores para a tomada de decição de descarga:
\begin{itemize}
\item velocidade relativa e utilização corrente dos servidores hospedeiros;
\item largura de banda e latência de rede em comunicação com os servidores hospedeiros;
\item complexidade das tarefas, considerado como uma estimativa de tempo de execução da tarefa;
\item tamanho da entrada e saída.
\end{itemize}

O grande diferencial do Scavenger é a técnica de perfil duplo utilizado, no qual dois perfils são gravados para cada tarefa. Um perfil é centrado na tarefa e utiliza um peso global para caracterizar o perfil. Outro perfil é centrado em \textit{peers} e criado para cada par de disposivo/tarefa.

Contudo, o \textit{framework} não trata a tolerância a falhas dos servidores hospedeiros. Em adição, os servidores hospedeiros são citados como computadores \textit{desktop} o que não fica claro se o \textit{framework} é muito pesado para execução em dispositivos móveis, o que tornaria os próprios dispositivos como hospedeiros.

\subsection{MAUI}
O MAUI \cite{cuervo:10} é um sistema que habilita descarga de código móvel em granularidade fina para uma infraestrura ciênte do consumo de energia. 
Abordagens anteriores para solucionar estes mesmos problemas eram baseadas no suporte intensivo do programador para particionar a aplicação, ou possuiam granularidade muito alta, tendo que migrar todo um processo ou VM. O MAUI beneficía-se de um ambiente de código gerenciável para oferecer o melhor entre as duas opções: suporta descarga de código com granularidade fina para maximizar a economia de energia ao passo que necessita mínima atenção do programador.

Implementado em .NET, o sisitema pode utilizar tanto 3G, quanto WiFi como mecanismos de comunicação. Desenvolvedores precisam anotar os métodos que podem ser descarregados para os servidores remotos. Ele decide em tempo de execução qual método deve ser executado remotamente, sendo controlado por um motor de otimização que prima pela melhor economia de energia possivel dentro das restrições correntes de conectividade do dispositivo móvel.

O MAUI contempla um analisador de custo benefício que cria perfils de cada método de uma aplicação através de serialização. Medidas de largura de banda e latência também são incorporadas ao custo. Mais especificamente, o criador de perfils do MAUI considera três problemas para compor o custo:
\begin{itemize}
\item utilização de energia do dispositivo composta por uso de bateria e ciclos de CPU;
\item características da aplicação pois o histórico de invocações passadas pode ser utilizado em detrimento a criação de um novo perfil;
\item características da rede com procedimentos para medir \textit{throughput}. 
\end{itemize}

Os dados adquiridos pelo mecanismo de criação de perfils é utilizado como entrada para \textit{Solver} que decide se um método deverá ser executado localmente ou remotamente. O \textit{Solver} tenta oferecer a melhor estratégia de particionamento que resulte no menor consumo de bateria do dispositivo.

\subsection{Análise comparativa dos \textit{frameworks} para nuvens móveis}
O Spectra é um dos sistemas mais antigos a utilizar modelo de custo centrado em perfils de histórico. Vários dos outros sistemas posteriores a ele trabalharam sobre os conceitos propostos, adicionando novas funcionalidades para endereçar suas desvantagens. Este é o caso do MAUI, que também assume que execuções passadas ou similares são bons indicadores do uso de recursos corrente, porém a energia consumida por uma operação é expressa como uma função do número de ciclos da CPU, e não medidas diretas da bateria do dispositivo. O Scavenger também armazana dado históricos e gerencia perfils de custo de forma similar ao Spectra, mas otimiza o conceito armazenando dois perfils por tarefa para diferentes fins.

Enquanto uma análise compreensiva de custo benefício para tomada de decisão de descarga é de extrema importancia para a otimização do desempenho, o custo desta análise não pode ser negligenciado. O MAUI discute esse problema, no qual a sobrecarga da execução frequênte da criação de perfis e as estimativas baseadas em dados passados são balanceados para oferecer o melhor resultado. Os outros sistemas não avaliaram este conceito, desconsiderando a escassez de recursos diponíveis em dispositivos móveis.

Estudos como o Hyrax apresentam um diferencial perante os demais: os própios dispositivos móveis atuam como provedores de recursos. Apesar se ser um estudo promissor, uma vez que os dispositivos móveis estão se popularizando, apresenta ainda uma série de lacunas principalmente à mecanismos descentralizados para nuvens \textit{ad hoc}. O Hyrax depende de um servidor central que é responsável pelo alocação de tarefas, característica herdada do Hadoop, portanto não suporta o escalonamento de tarefas descentralizado. Outro fato marcante do Hyrax é a falta de um mecanismo de avaliação de custo de descarga.

A migração de máquinas virtuais é o mecanismo mais utilizado para descarga de aplicação pela grande maioria dos \textit{frameworks}. A virtualização reduz muito o trabalho do programador, visto que poucas ou nenhuma parte do código da aplicação precisa ser reescrita. Entretanto, com a utilização de virtualização total com particionamento automático é improvável que seja reproduzida as mesmas otimizações granularizadas que uma aplicação manualmente escrita. Mas, reescrever todas aplicações para suportar a descarga de código também não é praticável. O MAUI utiliza uma combinação de migração de máquinas virtuais e particionamento programado pelo programador para balancear a granularidade das otimizações. Porém, em casos cujo dispositivo móvel encontra-se dentro da região de um servidor hospedeiro com um tempo limitado, a utilização de migração de VMs é computacionalmente muito pesada, de forma que a utilização de agentes móveis é bem mais adequada para estes ambientes dinâmicos.

A Tabela~\ref{tab:compmobicloud} mostra uma comparação dos sistemas de implementação de nuvens móveis analisando os modelos de avaliação de custo de descarga, a método utilizado para a descarga e os protocolos de comunicação utilizados.

\begin{table}
	\caption{Comparação dos \textit{frameworks} de nuvens móveis}
	\label{tab:compmobicloud}
	\centering%
	\begin{minipage}{\textwidth}
		\footnotesize
		\resizebox{\textwidth}{!} {
		\begin{tabular}{|l|l|l|l|l|l|l|}
			\hline
%           Header Line 1			
			\textbf{Nome} & \textbf{Modelo}   & \textbf{Método de} &
			\textbf{Objetivos} & \textbf{Recursos} & \textbf{Avaliação de} &
			\textbf{Protocolo de } \\
%           Header Line 2
			              & \textbf{de Custo} & \textbf{Descarga}  &   
			\textbf{do modelo} & \textbf{Analisados} & \textbf{Custo de}   &
			\textbf{Conexão}       \\		                  
%			Header Line 3
			              &               &                    &
            \textbf{de custos} &                   & \textbf{Perfil}	   &
			                       \\
			\hline
%			Line 1			
			Spectra & Perfil     & Comunicação      & Redução do tempo & CPU, rede, bateria & Não & WiFi \\
			        & baseado em & Cliente-Servidor & de execução, uso & cache de arquivos, &     &      \\
			        & histórico  &                  & de energia,      & CPU remota, uso de &     &      \\
			        &            &                  & aumento de       & memória e cache de &     &      \\
			        &            &                  & fidelidade       & arquivos remotos   &     &      \\
			\hline
%			Line 2			
			Hyrax & - & Comunicação      & - & - & Não & WiFi \\
			      &   & Cliente-Servidor &   &   &     &      \\
			      &   &                  &   &   &     &      \\
			      &   &                  &   &   &     &      \\
			\hline			
%			Line 3
			MobiCloud & Métodos      & Migração de     & Economia de & CPU, estado da & Não & WiFi \\
			          & estocásticos & Máquina Virtual & energia e   & bateria e rede &     &      \\
			          &              &                 & minimização &                &     &      \\
			          &              &                 & do custo    &                &     &      \\
			          &              &                 & monetário   &                &     &      \\
			\hline			
%			Line 4
			Cuckoo & Perfil     & Comunicação      & Execução de & Informações     & Não & WiFi      \\
			       & baseado em & Cliente-Servidor & tarefas     & de contexto,    &     & 3G        \\
			       & histórico  &                  & remotas     & disponibilidade &     & Bluetooth \\
			       &            &                  &             & de recursos     &     &           \\
			       &            &                  &             & remotos         &     &           \\
			\hline
%			Line 5
			Cloudlets & - & Migração de     & - & - & Não & WiFi \\
			          &   & Máquina Virtual &   &   &     &      \\
			\hline
%			Line 6
			CloneCloud & Perfil     & Migração de     & Redução do tempo & CPU, rede e   & Não & WiFi \\
			           & baseado em & Máquina Virtual & de execução, uso & armazenamento &     & 3G   \\
			           & histórico  &                 & de energia       &               &     &      \\
			\hline
%			Line 7
			Scavenger & Perfil     & Agentes Móveis & Melhorar o   & Nenhum & Não & WiFi \\
			          & baseado em &                & desempenho e &        &     &      \\
			          & histórico  &                & economia de  &        &     &      \\
			          &            &                & energia      &        &     &      \\
			\hline
%			Line 8
			MAUI & Perfil     & Migração de     & Economia de & CPU, latência & Sim & WiFi \\
			     & baseado em & Máquina Virtual & energia e   & e banda de    &     & 3G   \\
			     & histórico  &                 & velocidade  & rede          &     &      \\
			\hline
		\end{tabular}
		}
		\fonte{Elaborado pelo autor.}
	\end{minipage}
\end{table}

\section{Análise de Oportunidade de Pesquisa}

A nuvem móvel habilita que os dispostivos móveis sejam integrados tornando invisível aos componentes da nuvem a escasses de alguns recursos. 

--
Na parte de internet de coisas são citados três visões para a mesma:
Uma abordando coisas
Uma abordando redes
E por último abordando semântica

A abordagem das coisas já está em andamento bem avançado. A EPCglobal vem desenvolvendo um grande trabalho sobre esse assunto popularizando o RFID no produtos ordinários.
O NFC Forum vem trabalhando pesado também para alavancar e popularizar o uso do NFC. É cada vez mais comum encontrarmos novas aplicações que utilizem NFC. O NFC também possui um grande aliado: os smartphones. A grande maioria dos aparelhos já vem com suporte a tecnologia o que permite ler tags NFC ou operar no modo P2P entre os dispositivos.

Existem algumas tentativas também para unificar a rede global de computador com as "coisas". Abordagens que adicionam funcionalidade ao ipv6 paracem promissoras, porém não existe nenhum padrão consolidado no mercado para isso ainda.

A visão semantica é mais criteriosa ainda. Como armazenar e representar esses dados? Padronizar todo o tipo de informação que existe no mundo? Não parece uma grande ideia.

(com cara de conclusão)
Mas o que fazer com uma rede de coisas inteligentes interligadas? A imaginação é o limite da criatividade humana.
Quais são os tipos de serviços que podem ser oferecidos dentro deste contexto de rede ubíqua global?
Como os serviços que temos hoje serão afetados por esse novo paradigma de rede? Como podem ser melhorados?

--
Com a EPCglobal poderiamos acessar os dados de diversos produtos. Com o NFC nossos smarphones tornam-se nossos aliados no mundo da "coisas". Mas como integrar essaes dois mundos?
Como as "coisas" podem facilitar nossas vidas criando novos serviços?

Como foi citado anteriormente, a tecnologia empregada pelas \textit{tags} RFID  NFC e EPCglobal são fundamentalmente incompatíveis. Porém, não deixam de ser complementares. 

Uma oportunidade de pesquisa dentro desta linha, vem com ciência do contexto, conceito já bastante difundido. 
Tanto a EPCglobal como o NFC possuem abordagens reativas para os usuários. O usuário precisa querer de alguma forma saber uma informação sobre um produto para utilizar as tecnologias. Uma empresa pode ter alguns necessidades diferencida dos usuários, e necessitem de tal dinamismo precocemente. Porém a grande maiorio dos usuários, utiliza a tecnologia de forma reativa. Isso quando utiliza.

E se adicionarmos ciência do contexto nas "coisas"? E se as coisas pudessem detectar padrões, ações e atividades do usuários e auxiliassem autonomamente de forma próativa?

As "coisas" poderiam ter adordagens oportunisticas tomar ações sem a ação do usuário.

Para difundir esse tipo de serviço e facilitar a programação de aplicações que utilizem todas essas tecnologias seria interessante a criação de um middleware que integrasse tecnlogias de identificação (RFID) com redes móveis (WiFi, 3G/4G) com o objetivo de formar uma local mobile cloud.

-> Citar que o tipo de mobile cloud utilizada é a 2 abordagem, mobile P2P.

Desta forma, além de facilitar a programação de sistemas ciêntes do contexto dentro do conceito de de internet das coisas, as aplicações poderiam utilizar dados, informações e serviços de outros usuários oportunisticamente.

%=======================================================================
% Modelo para Comércio Eletrônico
%=======================================================================
\chapter{Modelo para Comercio Eletrônico}
Para melhor apresentar o modelo para o comércio eletrônico proposto neste 
trabalho, sugere-se primeiro um cenário cotidiano para exemplificar o 
funcionamento do sistema.

O usuário tem uma série de coisas, seja nos armarios ou nas geladeiras, que 
precisam ser repostas de tempos em tempos na medida em que o estoque vai se 
esgotando. Dado dia da semana, por exemplo, ele vai ao supermercado adquirir 
os produtos em falta.

À medida que produtos vão sendo consumidos de estoques locais, é criada uma 
lista de produtos a serem comprados com a finalidade de abastecer novamente o 
estoque local. Porém, durante a semana, sensores RFID nos armários, geladeiras 
e demais ambientes da casa poderiam controlar proativamente o consumo dos 
produtos e alertar dispositivos móveis das coisas que estão faltando, e 
popularem esta lista de produtos a serem comprados. 

Nesse meio tempo, o usuário dono do dispositivo móvel tem uma série de amigos, 
que também vivem a mesma rotina: os produtos são consumidos e precisam ser 
novamente adquiridos. Todavia, as rotinas dos usuários não são iguais, de 
forma que os amigos do usuário difícilmente iriam no mercado todos no mesmo 
dia. Desta forma, cada usuário do sistema, agora compreendendo também os 
amigos do usuário principal, possui uma experiência diferente de compra, ou 
seja, possui informações divergentes de um produto.  Uma vez compartilhadas, 
estas informações podem servir como entrada para outros usuários que ainda não 
realizaram suas compras, habilitando o sistema a incrementar a lista de 
produtos adicionando informações sobre preço e local de compra, por exemplo. 
De posse desta lista, o usuário já sabe exatamente em qual estabelecimento 
deve ir para adquirir o produto com o menor preço, assegurando a economia nas 
compras.

Esse esquema de interação dos usuários caracteriza uma nuvem móvel. Ou seja, o 
usuário pode estar no transito, num shopping, ou qualquer outro lugar, e 
dependendo do nível de segurança, é possivel trocar informações sobre produtos 
com outras pessoas.

Com a integração dos dispositivos móveis e de sensoriamento RFID, é possível  
estabelecer um rastreamento dos produtos adquiridos, formando um histórico de 
compras. Este histórico de compras que pode estar tanto localmente nos 
dispositivos dos usuários de forma descentralizadas, como ainda ser 
compartilhado em alguma rede social. Ou seja, o dispositivo móvel quando 
ocioso recebe notificações da rede social com dados referentes a compra de um 
determinado produto. Ainda, o próprio supermercado pode analisar as 
informações sugerindo novas ofertas e enviando tanto para a rede, como para os 
dispositivos dos usuários.

Na medida em que os históricos de compras dos usuários vão sendo populados, 
pode haver a sugestão de produtos e descontos especializados para cada 
cliente. Assim, a experiência de compra de cada cliente seria modificada, 
tornando-se única e adaptada aos gostos e preferências de cada um. 
Semelhantemente, os usuários poderiam avaliar os produtos e lojas, 
estabelecendo uma reputação para os produtos e serviços oferecidos, de forma 
que a conveniência também seja levada em consideração na hora de compor a 
lista com as melhores oportunidades.

Assim, cada item adicionado à lista de compras dispara um processo de busca 
pelas melhores ofertas. Oportunisticamente, o sistema integrado através de uma 
nuvem móvel, busca informações de outros usuários que efetuaram a compra do 
mesmo produto em diferentes lojas. Desta forma, o sistema torna-se ciente do 
contexto canalizando as informações importantes, e disponibilizando 
informações relevantes para a tomada de decisão do usuário.

A computação na nuvem móvel ainda permitiria o compartilhamento de recursos. 
Cada dispositivo móvel é dotado de diferentes tipos de sensores. Quando um 
dispositivo é integrado a nuvem móvel, ele passa a compartilhar suas 
funcionalidade com os demais componentes do grupo. Por exemplo, um dispositivo 
que encontra-se em uma rede de sensores RFID pode servir como ponte de 
comunicação para outros dispositivos geográficamente longes e sem acesso a 
essa rede. Logo, somente por estar localizado em uma área com tais 
funcionalidades, todos os integrantes da nuvem móvel podem beneficiar-se 
destes serviços oferecidos.

Portanto, o sistema trata-se de uma nuvem móvel, no qual os dispositivos se 
complementam em questão de recursos. Uma vez que um dispositivo móvel 
encontra-se em um ambiente dotado de sensores RFID, essa leitura dos sensores 
torna-se disponível na nuvem como um serviço. Assim, outros dispositivos 
móveis interconectados na nuvem móvel podem utilizar este novo serviço 
oportunisticamente devido a localização de um dos membros frente à rede de 
sensores RFID.

Sumarizando, a nuvem móvel poderia inferir as melhores ofertas de um produto 
de duas formas:
\begin{itemize}
\item serviços de leitura de sensores oportunizados por dispositivos em determinados contextos de localização;
\item busca nos históricos recentes de outros dispositivos.
\end{itemize}

\section{Decisões de Projeto}
Para possibilitar o modelo de comunicação na nuvem móvel, esta sendo analisado  
a utilização de bibliotecas de compartilhamento \textit{Peer-to-Peer} entre os 
dispositivos. 

As redes sociais apresentam uma forma simples para compartilhamento de 
informações entre amigos e possui mecanismos de segurança e privacidade 
inerentes. Uma vez que certa pessoa é dada como amigo, o sistema está apto a 
compartilhar informações com ela, pois está estabelecido uma relação de 
confiança entre os usuários. Ainda não está definido quais redes sociais 
poderiam ser utilizadas em conjunto com o sistema.

As necessidades de um \textit{middleware} NFC são bem menores que as 
necessidade de um sistema EPC. Apesar de trabalhar-se com as duas abordagens, 
a utilização de NFC não depende de infraestura externa para criação de 
protótipos, enquanto a rede EPC demanda de uma vasta quantidade de sistemas 
mesmo para funcionalidade minimalistas. A aplicação proposta tem em vista criar um modelo de computação oportunistica para os usuários, logo, a tecnologia NFC permite utilizar os próprios dispositivos móveis (\textit{smartphones}) dos usuários para efetuar a leitura das \textit{tags} RFID. Esta abordagem reduz também o investimento das redes de supermercados para habilitar a identificação dos produtos.

\section{Modelagem Inicial}
A ideia de buscar o oportunismo nas nuvens móveis, nos remete as visões da 
internet das coisas. A caracterísitica mais básica do sistema é a capacidade 
de identificar os objetos que contém \textit{tags} RFID. Porém, a operação da 
nuvem móvel só é concretizada com a comunicação entre os dispositivos móveis. 
Mas para as informações dos objetos serem comunicadas através da rede é 
necessário ter uma necessidade para isso. Logo, o sistema está diretamente 
ligado com as três visões da internet das coisas.

\subsection{Modelo de comunicação}
O oportunismo da rede encontra-se na necessidade de utilização de serviços e 
do conhecimento distribuído que a rede apresenta. Nem todos os dispositivos 
móveis apresentam os mesmos recursos computacionais nem sensorias. Por 
exemplo, são poucos os dispositivos que contém suporte a tecnologia NFC. 
Porém, quando os mesmos estiverem ligados à nuvem móvel, outros dispositivos 
incapazes de executar tal ação poderão utilizar este novo recurso. Portanto, a 
utilização de um novo serviço trata-se de oportunidade, uma vez que a nuvem 
deve conter um dispositivo apto a executar tal ação e localizado em um 
ambiente adequado.

O conhecimento da nuvem é obtido por meio dos históricos que serão gerados no 
decorrer de seu uso. Então, mesmo que não exista um serviço disponível em dado 
momento na rede, por causa da localização de algum dispositivo, a rede ainda 
conta com o histórico de atividades realizadas.

As trocas de informações entre so usuários podem ser tanto ativas como 
passivas. No processo ativo, o próprio usuário faz com que as informações de 
um produto sejam compartilhadas, seja via rede social, ou comunicação direta 
com os outros dispositivos. A utilização das redes sociais permitiria ainda 
que promoções fossem oferecidas diretamente pelo supermercado para a nuvem 
móvel dos usuários. Tal abordagem, fortalece ainda mais o oportunismo da rede, 
já que permite o compartilhamento de informações extras entre os usuários. 
Descontos promocionais em produtos podem ser de interesse de outros usuários 
mesmo quando não se encontram na lista de produtos essenciais. O processo 
passivo é dado periodicamente pelo próprio dispositivos. Dentro de 
determinados ciclos, o dispositivo pergunta à nuvem se algum outro dispositivo 
tem novidades sobre os produto que se encontra em sua lista.

Este modelo de comunicação pode ser visto como \textit{push}-\textit{pull}. 
Tanto a abordagem passiva como a ativa, faria uso deste modelo. Durante o 
compartilhamento ativo, um dispositivo iria enviar as informações de um 
produto (\textit{push}) para os demais dispositivos mesmo sem ter sido 
requisitado. Como tratar as informações recebidas fica a cargo das 
configurações dos outros dispositivos. Inicialmente as seguintes operações 
estão sendo analisadas:
\begin{itemize}
\item as informações podem coincidir com os produtos que estão na lista, sendo  atualizadas;
\item as informações podem ser armazenadas para uso futuro;
\item as informações podem ser exibidas para o usuário;
\item as informações podem ser descartadas;
\end{itemize}

Já o compartilhamento passivo implica na interrogação das informações por 
parte de algum dispositivo (\textit{pull}). Periodicamente, um dispositivo 
envia uma mensagem para os demais requisitando informações sobre determinado 
produto. Caso, algum dispositivo tenha estas informações, o mesmo as retorna  para o requerente. A Figura~\ref{fig:model:com} ilustra as duas abordagens do modelo \textit{push}-\textit{pull}. As setas em verde no modelo \textit{push} simbolizam o compartilhamento de uma informação com os demais dispositivos. As setas verdes no modelo \textit{pull} simbolizam o questionamento de informações aos participantes da nuvem móvel, enquanto as setas vermelhas mostram o retorno das informações.

\begin{figure}
	\caption{Modelo de comunicação \textit{push}-\textit{pull}.}
	\label{fig:model:com}
	\centering%
	\begin{minipage}{\textwidth}
		\includegraphics[width=\textwidth]{Figuras/model-com.eps}
		\fonte{Elaborado pelo autor.}
	\end{minipage}
\end{figure}

\subsection{Modelo de identificação}
É necessário também uma infraestrutura RFID na rede do mercado para habilitar 
a execução do modelo. As duas tecnologias mais bem difundidas para 
identificação de produtos com RFID, como já visto anteriormente, são: 
EPCglobal e NFC. Nesta sessão serão tratados duas propostas para a 
infraestrturua do mercado, uma identificando todos os produtos do mercado, e 
outra identificando apenas as prateleiras onde os produtos se encontram. Para 
cada proposta de infraestrutura, as duas tecnologias são avaliadas mostrando 
pontos positivos e negativos de cada uma.

\subsubsection{Infraestrutura de tags em cada produto}
Esta abordagem requer a utilização de \textit{tags} em todos os produtos do 
mercado. Para controlar de forma eficiente todas as \textit{tags} distribuídas 
em meio aos produtos, um sistema centralizado de leitura de \textit{tags} faz-
se necessário.

A infraestrutura requerida por uma rede EPC é bem complexa, dotada de vários 
sistemas diferenciados e uma rede de leitores muito bem posicionados para 
alcançar todos os produtos. Para suportar a demanda de leituras, um 
\textit{middleware} centralizado baseado em ALE deveria ser utilizado. Porém, 
ela oferece serviços de identificação de produtos muito flexíveis, pois 
baseia-se em protocolos de comunicação padrões. Uma aplicação que utilizasse 
esta rede poderia compor consultas complexas e personalizadas para os leitores 
RFID. Outro ponto a destacar, o ONS em conjunto do EPC-DS forneceriam serviços 
de consultas que habilitaria os próprios dispositivos móveis à terem acesso as 
informações dos produtos por meio do consumo de \textit{web services}.

A utilização de \textit{tags} NFC, possui um agravente em sua implementação. A 
leitura só é possível em distancias muito curtas, dada utilização de 
\textit{tags} passivas. Essa característica passiva encurtaria a abrangência 
do sistema, possibilitando a leitura dos produtos apenas ao alcance dos 
sensores, que é bem pequena. Desta forma, o sistema precisaria de mais 
leitores que sua implementação com EPCglobal. 

\subsubsection{Infraestrutura de tags nas prateleiras}
Esta abordagem simplifica significativamente a infraestrutura do mercado. Ao 
invés de cada produto conter uma \textit{tag}, somente a prateleira cujo 
produto está alocado possuiria tal identificação. Como a sobreposição de 
\textit{tags} é muito menor com esta aboragem, o sistema não precisaria 
obrigatoriamente de um sistema centralizado de leitura.

Visando simplificar ainda mais a arquitetura desta infraestrutura, a 
utilização de \textit{tags} NFC poderiam substituir a necessidade do uso de 
leitores de RFID específicos por dispositivos móveis do próprio consumidor, 
desta que dotados desta tecnologia. Com isso, a infraestrutura do mercado não 
precisaria conter leitores alocados em posições estratégicas, nem possuir um 
sistema de gerenciamento de leituras. Toda a leitura seria iniciada pelo 
próprio consumir em frente à prateleira de produtos direto de seu dispositivo 
móvel. Porém, perde-se todo o rastreamento dos produtos oferecido por uma rede 
EPC.

Uma rede EPC traria elementos desnecessários para esta infraestrutura. O 
principal objetivo da rede EPC é identificar unicamente cada produto, porém 
com a instalação da \textit{tag} na prateleira, não existira identificação 
exclusiva para um produto, mas sim coletiva para um grupo de produtos. O 
sistema centralizado de leitura seria subutilizado, pois não haveriam  sobre-
posições de \textit{tags} que demandassem poder computacional.

\section{Ideas para Avaliação}

%=======================================================================
% Conclusão
%=======================================================================
\chapter{Conclusão}

\section{Contribuições Esperadas}
- abordar o tema do trabalho
- propor a solução dada ao problema
  - dizer que eh possivel criar um software para impulsionar o mercado atraves do oportunismo...
- citar a comparação de trabalhos de atuais, estado da arte
- descrever os modelos citados
- introduzir próximoas sessoes

"
Um parágrafo introdutório sobre o seu tema monografico
Uma frase ou duas sobre as hipóteses de pesquisa e os objetivos principais e como estes foram alcançados.
Apresentação da metodologia abordada juntamente com alguns resultados. Não mais que um parágrafo da conclusão deverá ser dedicado a este ponto. 
Descrição de alguma dificuldade apresentada durante a elaboração da pesquisa.
Exposição analítica dos resultados encontrados. Você vai dedicar o maior número de parágrafos nesta tarefa.
Apontamento das consequências geradas pelos resultados anteriormente apresentados. Aqui cabe dedicar um ou no máximo dois parágrafos de sua conclusão. 
Finalização do campo conclusivo com um parágrafo sobre o que você faria se tivesse mais tempo ou recursos, ou então que você recomendaria a outros que continuassem seu trabalho.
"

\begin{itemize}
\item um modelo de programação que viabilize o oportunismo de compartilhamento entre dispositivos
\item 
\item
\end{itemize}

\section{Cronograma e Trabalhos Futuros}
- Integração com multi-hop ad-hoc networks

multi-hop ad hov networks parecem ser um caminho natural que a conectivadade da internet e das coisas tende a seguir, neste conexto, o trabalho poderia se extender para a aplicação deste conceito de compartilhamento oportunistico de recursos em uma rede ad hoc, sem a dependencia de servidores centralizados.

In this work, we considered Scribe as a p2p multicast system, since it has shown good
performance over legacy wired networks. However, experimental results demonstrated its
major inefficiencies when it is used over ad hoc networks. Therefore, we presented and
evaluated XScribe, which is a simple cross-layer replacement for Scribe, designed for
multi-hop ad hoc networks.

avaliacao de middlewares P2P em multi hop ad hoc networks, como crossROADS e XScribe.

%=======================================================================
% Referências
%=======================================================================
\bibliography{monografia}

%=======================================================================
% Exemplo de Apêndice
% O Apêndice é utilizado para apresentar material complementar elaborado
% pelo próprio autor.  Deve seguir as mesmas regras de formatação do
% corpo principal do documento.
%=======================================================================
\appendix
\chapter{Informações Complementares}

O Apêndice é o lugar para incluir textos complementares, que não são essenciais para o entendimento do assunto principal da monografia, mas que podem contribuir com informação relevante (por exemplo, uma prova matemática, uma conceituação básica, etc.).  Ele deve seguir o formato normal do documento.

%=======================================================================
% Exemplo de Anexo
% O Anexo é utilizado para a ``inclusão de materiais não elaborados pelo
% próprio autor, como cópias de artigos, manuais, folders, balancetes, etc.
% e não precisam estar em conformidade com o modelo''.
%=======================================================================
\annex
\chapter{Artigos Publicados}
Existe diferença entre os Apêndices e os Anexos.  Os apêndices trazem informação escrita pelo próprio autor do trabalho, incorporando-se ao formato da monografia como um todo.  Já um anexo é um material à parte, definido/publicado por si só, e que o autor julga conveniente ser apresentado juntamente com a monografia.  Normalmente também vai apresentar formato próprio, como um artigo publicado, um folder, uma planilha, etc.
\end{document}
